Add sync-waves/dependencies at the application level

[smallc2009]

Summary

We'd like to see application-level sync waves where we can express dependencies at the application level.

Motivation

Our product is made of different microservices, echo microservice has its own deployment folder. we deploy these folders as applications in ArgoCD.

For example, our core service is called the Base which is a fundamental service, and other services depend on it. we usually upgrade them together, we need to upgrade the Base first, then other services. so we need application-level dependencies, the Base application in Argocd get ready, then other applications start syncing.

Proposal

I'd personally prefer application dependencies through app-sync-waves=1, or based on the application title, like 1-base, 2-rest.

[tdnguyen6]

It has been more than 2 months for since issue was created. Is there any temporary workaround for this?

[shukla2009]

+1

[terrytangyuan]

You'll have to enable health assessment for Application CRD. See instructions in https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/1.7-1.8/#health-assessment-of-argoprojioapplication-crd-has-been-removed

[flaviomoringa]

This would be extremely useful.

Right now I have an issue installing Kyverno and then some policies that needs exactly this, because Kyverno CRD's need to be in place first. It it's not the policies will fail and enter a kind of crashloopback state.

The issue is like this one: #8358

I did not understood how enabling health assessment for Application CRD would help with this.

Thanks

[jimmyjones2]

Enabling health assessment on Application CRDs only works if you're using an app-of-apps pattern - ie. it would only progress onto an Application in the next sync-wave if the previous were healthy.

[karlschriek]

I would actually like to see the ability to explicitly define dependency between two applications. E.g.:

App1 doesn't depend on anything:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: App1
spec:
  project: default
  ...

App2 to depends on App1 and will only start syncing if App1 has been synced. If App1 re-syncs, App2 will re-sync as well after App1's sync has completed.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: App2
  annotations:
    argocd.argoproj.io/depends-on: default/App1
spec:
  project: default
  ...

I can understand how the current sync-wave approach works only with the app-of-apps approach. Because how would I otherwise prevent App2 from syncing before App1? What if App1 doesn't even exist yet? That is actually the use case that we have. We generate a series of Apps dynamically (and since we don't know what they will be beforehand, we can't use app-of-apps) and in an arbitrary order. But we do want to be able to deploy them in a specific order. We would like to be able to annotate App2 to depend on App1 (and have it wait forever if App1 never comes into existence) in a similar way as you would use depends_on in Terraform for example.

EDIT: This is essentially the same as what is suggested here: #3454

[JordanYefet]

This is a must-have feature, especially when using helm charts from external repositories, where you can't (and don't want to) modify the K8s YAMLs.

Thanks.

[cdtzabra]

I also need this feature

I have to deploy cloudnative-pg postgres operator first with their Helm chart without any modification
Then create a postgres cluster instance as a separate application.

But Cluster instance application need to be created only after the operator.

If I deploy manually, I can deploy the operator first and then the cluster instance(workaround) BUT the final goal is to automate the deployment or use an appset which will include many applications

[blakepettersson]

Duplicate of #7437