Proposal: support multiple sources for an Application

[fabriziofortino]

Currently, an Application supports a single ApplicationSource. In some scenario it would be useful to support more than one source.

Here is a typical example: we have an Application that uses the elasticsearch helm chart as source. We need to create a separate Application to configure the elasticsearch-exporter to expose Prometheus metrics.

From a logical point of view, these could be seen as a single application. In this way, the application can be composed using different sources/charts. What do you think? 🙇

[alexmt]

Great idea! I've faced the same scenario today and had to copy manifests of one app into another app. The composable app would be much cleaner.

We would have to provide some way to solve possible naming conflicts. E.g. if two helm charts create deployments with the same name it should be possible to use different release names for each chart

[jessesuen]

Specifying multiple sources can now be accommodated by the configuration management plugins. I think adding native support multiple sources will complicate the implementation too greatly.

[alexec]

I think you can use app-of-apps to solve this? https://argoproj.github.io/argo-cd/operator-manual/cluster-bootstrapping/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[epinzur]

App-of-apps can take care of this, but I think it would be cleaner if the Application object itself could support multiple helm charts. I realize this would complicate the ArgoCD implementation, but I think it would improve the user experience greatly.

[robseidel]

In our company we want to use different levels in our ops repositories, like global/cluster/application. We are already using a custom management plugin to get all these things together, but we are running into the problem, that argo syncs only a single source. So if the application config gets changed, argo recognize the change and start the deployment, but if the cluster configuration gets changed, nothing happens. The only way to sync such changes is manually refresh/hard or sync apps/force.

[jessesuen]

I think adding native support multiple sources will complicate the implementation too greatly.

We originally eschewed this feature due to the added complexity of supporting 2+ sources for a single application. However, due to the refactoring needed to support #2789, we are now reconsidering this feature.

Reopening.

[karlschriek]

This would be very interesting for us as well. We already use "Application of Application" approaches, which is a nice way to group a bunch of related applications and roll them all out with just a single kubectl command. However, when semantically you are rolling out a single application, but you need to construct it from different sources, a "multi-source" Application makes more sense.

A typical use case we have is rolling out a Helm chart and setting something like secret.create or serviceAccount.create to false. We would then create those resources separately. It would be nice to have something like this in order to accommodate this:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: oauth2-proxy
  namespace: argocd
spec:
  project: default    
  destination:
    namespace: oauth2-proxy
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
  sources:
  - chart: oauth2-proxy
    helm:
      parameters:
      - name: configSecret.create
        value: 'false'
      - name: config.existingSecret"
        value: oauth2-proxy
        ...
    repoURL: https://oauth2-proxy.github.io/manifests
    targetRevision: 4.2.2
    ...
  - repoURL: https://github.com/myorg/myrepo
    targetRevision: sometag
    path: path/to/secret
    ...

[RafPe]

I am also looking for this! Would make life so much easier when deploying applications which co-exist together!

[blackandred]

For me the use case would be to install Helm & provide externally a secret that Helm requires but does not create. The same for service accounts and optional configmaps.

[Jojoooo1]

Would be very great to have! My use case would be to use the chart of chart pattern directly in argo!

[subhashchy]

Would be great for us to have as well. For us each application is a set of Frontend, edge-api-gateway, redis and 2 different edge workers.

[joebowbeer]

See #2789 (comment)

[danielbraun89]

The use case of creating a cluster-role and a role-binding for an app, separately, is ridiculously common
Many Helm charts create service-accounts for you but understandably never create the roles, and currently this adds another annoying layer of provisioning alongside argocd

[blackandred]

I have a workaround for this - it may be helpful for somebody.

Instead of using Helm directly use Helm via Kustomize - just set a source type in kind: Application to point to a kustomization.yaml, and in kustomization.yaml use e.g. Helm Chart, or multiple Helm Charts + plain YAML resources you would like to mix as part of one application.

In order to use Helm in kustomize you need also to change the build args in argocd-cm to enable helm during kustomize build.

[keskad]

I wrote about this topic on my blog, maybe somebody could be interested on how to handle this in few different ways: https://medium.com/p/424bc3a6bc8