whitleykeith commented 4 years ago

Summary

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

Motivation

Currently our team provides a "platform" to other teams within our company in a multi-tenant cluster where each team has their own config repo. When we initially move clusters, there's a bit of tribal knowledge involved to ensure the projects/apps get created in the right order.

Since most teams apps are already in an App-of-Apps design, we dont want to have to unify all of the config repos into another app in order to define sync waves. We'd prefer a way of defining projects with either dependencies or sync waves to express this

Proposal

I'd personally prefer direct dependencies called out such as ProjectA dependsOn ProjectB but a sync waves implementation is fine and aligns more closely to the current argo design.

jannfis commented 4 years ago

Some similar thought was recently expressed in #3517, and I think this would be a really good feature to have.

I was thinking about something like "named sync waves", so instead just specifying a wave number in argocd.argoproj.io/sync-wave, one could specify i.e. wave-a/x, where x is the order of the wave within the wave wave-a. This could allow for defining dependencies such as argocd.argoproj.io/sync-wave-depends: wave-a (possibly with a list of waves the current wave is dependent upon), and ultimately would allow for defining multiple, independent waves to execute simultaneously.

To not break current behaviour, if no wave name is specified in the annotation, a default built-in wave is assumed and the wave executes just normally. This built-in wave could be project specific by using a configuration toggle, so each project would have its own default wave optionally.

I have not dug into the reconciliation code that far to see whether this would be possible in the current construct, but imho, would be a good way to go.

jannfis commented 4 years ago

Or after reading #3517 again, maybe specifying a dependency to an application such as argocd.argoproj.io/depends-on-app: app-a (or even a dedicated field in the Application CRD) might be the better, less complex solution. :thinking:

Anyway, this requires some discussion and design in the first place.

ghostsquad commented 4 years ago

This sounds like Directed Acyclical Graph support instead of just sequential "stages".

whitleykeith commented 4 years ago

IMO that's the "ideal" solution. That solves the project level dependencies as well as simplifying our current sync wave layout (we have some 30-40 apps with differing dependencies, including a self-managed argo instance).

Since app names are unique you just implement a DAG solution at the app level and allow apps to reference apps not in their project.

The less optimal solution is to have sync waves at the project level, but you run the risk of having a bad upstream project prevent updates to any other project, even if the app your project depends on is fine.

i.e.

Upstream Project A has 10 apps, all downstream apps depend on App A.

Project A has an app B that's degraded and can't sync, so Project A is unhealthy which means all downstream projects are unable to update until the team owning Project A fixes App B.

With a DAG you could have everyone depend on just App A, which prevents this from happening.