Argo-cd: Kustomize plugins, transformers and generators

[mousavian]

Is your feature request related to a problem? Please describe.
Is there any plan to support custom generator and transformer plugins introduced in Kustomize v2.1.0/v3?

Describe the solution you'd like
I expect when my app is being provisioned by a kustomization file which contains transformer or generator, possibly available in XDG_CONFIG_HOME path, argo-cd uses them as kustomize tool executes them in some defined order to generate final manifests.

An example could be like:
kustomization.yaml:

kind: Kustomization
resources:
- deployment.yaml

transformers:
- sedtransformer.yaml # https://github.com/kubernetes-sigs/kustomize/tree/a7df00c/plugin/someteam.example.com/v1/sedtransformer

sedtransformer.yaml:

apiVersion: someteam.example.com/v1
kind: SedTransformer
metadata:
  name: sed-transformat-plugin
argsOneLiner: s/one/two/g

So that all ones will be replaced by two.

Have you thought about contributing yourself?
I haven't particularly looked into that part of source code; but depends on the complexity and the time it needs, I may be able to.

[alexec]

Not yet. It'd be great to hear your use cases.

[jessesuen]

Transformers and generators should just work. These files are relative to your kustomize directory, so your git repo should have the transformers sitting somewhere near your kustomization.yaml.

As for plugins, this is also supported today, but you will need to customize your repo server with a custom image containing:

1. the plugins installed somewhere
2. setting XDG_CONFIG_HOME to that somewhere

See: https://argoproj.github.io/argo-cd/operator-manual/custom_tools/#byoi-build-your-own-image on a pattern to build your own image.

[mousavian]

In my use-case, I have an application that creates other applications in my cluster using cluster bootstrapping pattern.

Hence I have one Kustomization file per each app/service containing one resource, which is argo's kind: Application manifest. Here's a high level of dir structure:

.
├── apps
│   ├── kustomization.yaml # a base referencing all argoproj/Application manifests (resources: [my-service-1,...])
│   │
│   ├── my-service-1
│   │   ├── application.yaml # argoproj/Application manifest
│   │   └── kustomization.yaml
│   ├── my-service-2
│   │   ├── application.yaml
│   │   └── kustomization.yaml
│   └─...
└── clusters
    ├── staging
    │   └── kustomization.yaml # bases/resources: [../../apps]
    └── prod
        └── kustomization.yaml

Having this structure, I expect by executing command below, all of my apps get created in targeted cluster:

argocd app create applications  --path clusters/staging --...

The problem is in each Application manifest, destionation.server (& some other metadata) is different for each environment (staging vs prod), so I have few options:

• Provide multiple overlays for each Application
• Provide a patch in each cluster kustomization file so that we override destionation.server but then I have to reference all of my services individually for matchLabels to work.
  
  
  
  • Using transformers as a work around, specifically sedTransformer as a workaround to replace all destination.server: $SERVER with actual value
  
  
  • Wait for bulk editing feature which can update multiple targets to be implemented in kustomize (https://github.com/kubernetes-sigs/kustomize/issues/720)
  
  

I prefer to go with 3rd option as others are either WIP or add unnecessary complexity to the structure.
But when I've tried this, an error is thrown saying kustomize build /tmp/git@.... failed: Error: json: unknown field \"transformers\"\n" because Transformers is not defined in ApplicationSource. In fact, many fields are missing eg patches, bases, etc.

[mousavian]

Seems @jessesuen is right. :)
Error: json: unknown field "transformers" is kustomize v 2.0 error.
By bringing kustomize v2.1.0 in my own image it solves my issue.

Thanks!

[imakewebthings]

I know this is a relatively old and closed issue, but dropping this here in case it helps anyone. We had a desire for using plugins that are included in the target git repo, relative to the repo root. All it took was a config management plugin like so:

configManagementPlugins: |
  - name: kustomize-with-local-plugins
    generate:
      command: ["sh", "-c"]
      args: ["XDG_CONFIG_HOME=$(pwd | cut -d/ -f 1-3) kustomize build --enable_alpha_plugins"]