argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.76k stars 5.42k forks source link

Manifest generation error: multiple application sources defined: Helm,Plugin #13413

Open yitzhtal opened 1 year ago

yitzhtal commented 1 year ago

Checklist:

Hi, when using Helm for declaring values files along Plugin for secrets integration on an Application object, I receive the following error:

rpc error: code = Unknown desc = Manifest generation error (cached): multiple application sources defined: Helm,Plugin

To Reproduce

    spec:
      syncPolicy:
        syncOptions:
          - CreateNamespace=true
      project: "argo-rollouts"
      source:
        repoURL: https://git.info/scm/devops/argo-projects.git
        targetRevision: HEAD
        path: 'argocd-repos/argo-rollouts/development'
        plugin:
          name: argocd-vault-plugin
          env:
            - name: helm_args
              value: -f values.yaml -n saas-argo-rollouts
        helm:
          valueFiles: []

It makes sense to use both if I need the plugin for secrets integration...

Version

argocd: v2.6.7+5bcd846.dirty
  BuildDate: 2023-03-23T17:30:29Z
  GitCommit: 5bcd846fa16e4b19d8f477de7da50ec0aef320e5
  GitTreeState: dirty
  GoVersion: go1.20.2
  Compiler: gc
  Platform: darwin/amd64
argocd-server: v2.6.7+5bcd846
  BuildDate: 2023-03-23T14:57:27Z
  GitCommit: 5bcd846fa16e4b19d8f477de7da50ec0aef320e5
  GitTreeState: clean
  GoVersion: go1.18.10
  Compiler: gc
  Platform: linux/amd64
  Kustomize Version: v4.5.7 2022-08-02T16:35:54Z
  Helm Version: v3.10.3+g835b733
  Kubectl Version: v0.24.2
  Jsonnet Version: v0.19.1
werne2j commented 1 year ago

If you use AVP, you can’t use the native Helm integration. If you remove:

helm:
  valueFiles: []

That error will go away.

AVP with Helm docs: https://argocd-vault-plugin.readthedocs.io/en/stable/usage/#with-helm

Kulagin-G commented 1 year ago

ArgoCD ver: v2.7.6+00c914a.dirty

Today I had a plan to test CMP feature with our Applications but got an issue trying to add a test plugin to the manifest:

source:
  plugin:
    name: my-plugin-v1.0
    env:
      - name: FOO
         value: bar
  repoURL: >-
    git@git...
  path: environments
  targetRevision: HEAD
  helm:
    valueFiles:
      - values.yaml
      - ../../../../../globalOverrides/common-overrides.yaml
destination:
  server: 'https://kubernetes.default.svc'
  namespace: argocd
syncPolicy:
  automated:
    prune: true
    selfHeal: true

UI returns the same error as topic starter mentioned:

Unable to save changes: error validating and updating app: error validating and normalizing app: error validating the repo: error verifying source type: multiple application sources defined: Helm,Plugin

If it's expected and there are no options to use plugins with helm source together, please add this information to the documentation. BTW, this feature looks perspective and it's quite sad if ArgoCD doesn't support it in case with Helm as a source.

crenshaw-dev commented 1 year ago

If it's expected and there are no options to use plugins with helm source together,

Correct, you cannot use helm options and plugin options in the same source. This is because there is no guarantee that a plugin implements any of the options for Helm manifest generation (or kustomize or jsonnet for that manner). You can always configure your plugin to accept a value files list as an env var.

please add this information to the documentation.

I'd be happy to review a docs PR to clarify.

this feature looks perspective and it's quite sad if ArgoCD doesn't support it in case with Helm as a source.

Argo CD does support plugins using Helm sources. But defining what parameters the plugin accepts is entirely up to the plugin author. Argo CD will not translate the parameters for built-in Helm support into parameters for a plugin.

Kulagin-G commented 1 year ago

Argo CD does support plugins using Helm sources. But defining what parameters the plugin accepts is entirely up to the plugin author. Argo CD will not translate the parameters for built-in Helm support into parameters for a plugin.

Thank you for your quick response.

I'm not sure I got you fully correct but could you please check my thoughts and let me know whether it's possible to realize or not via CMP feature?

My proposal is to prepare a custom plugin to replace some placeholders in Helm's values on the fly before the manifest is generated and do the same for each refresh/sync action. It sounds like GitOps anti-pattern but it brings a profit for advanced config management. Just a proposal for the experiment to use additional data preparation on the step before manifest generation.

The overall plan is:

  1. Read uploaded values from an uploaded repo before manifest rendering/generation;
  2. Replace custom placeholders in values.yaml based on plugins' logic;
  3. Return to ArgoCD updated values.yaml for manifest generation.

Thank you in advance for any feedback even if you'll say it's an anti-pattern and stupid idea.

crenshaw-dev commented 1 year ago

It sounds like GitOps anti-pattern but it brings a profit for advanced config management.

Yep, it's a common pattern! It's good to be pragmatic about GitOps. It doesn't solve every use case. :-)

The overall plan is:

I like steps 1 and 2. Step 3 won't work given the way CMPs currently work. A CMP can't take partial responsibility for manifest generation - i.e. it can't just replace things in values.yaml and then pass the result back to Argo CD to run helm template. The CMP has to replace things in values.yaml and then also run helm template to return manifests.

adyanth commented 3 weeks ago

Could the plugin run on the output of the native helm plugin or is this something that is not planned on being supported? The downside (for me) of using AVP is that I lose the native helm plugin supporting multiple values files, which I would need to emulate now.