RollingSync strategy for multiple ApplicationSets

[alexymantha]

Summary

Add a way to define a RollingSync strategy in one place and refer to it in different ApplicationSets

Motivation

The RollingSync strategy for Progressive Sync requires the steps to be defined in the ApplicationSet. This leads to a lot of duplication because there are often common patterns for strategy, especially across a team's ApplicationSets. It would be a good QoL improvement if we could define the strategy in one place and refer to it in other ApplicationSets.

Proposal

A CRD to define the strategy:

apiVersion: argoproj.io/v1alpha1
kind: SyncStrategy
metadata:
  name: region-strategy
spec:
  type: RollingSync
  steps:
    - matchExpressions:
      - key: region 
        operator: In
        values:
          - apac
    - matchExpressions:
      - key: region
        operator: In
        values:
          - emea
        maxUpdate: 10%
    - matchExpressions:
      - key: region
        operator: In
        values:
          - na-west
        maxUpdate: 100%

In the ApplicationSet, refer to the resource instead:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - list:
      elements:
      - cluster: cluster1
        region: apac
      - cluster: cluster2
        region: emea
      - cluster: cluster3 
        region: na-west
  strategyRef:
	name: region-strategy
    namespace: argocd

[alexymantha]

Since this is specific to the Progressive Sync feature, can someone add the appset/progressive-sync label please?

[crenshaw-dev]

Sounds cool. With 2.8 introducing applicationsets-in-any-namespace, we probably need something like stragegyRef: {name: xyz, namespace abc}, with the namespace assumed to be the appset controller's namespace if none is specified.

Should we move the type field into the CRD as well? Seems like those are tightly-coupled.

[alexymantha]

You're right, forgot about the namespace. I edited the issue with your suggestion and changed the kind from RollingSyncStrategy to SyncStrategy it makes more sense if it also contains the type.

[wmgroot]

One alternative to needing the namespace for reference is to add namespace and cluster-scoped CRDs for re-usable sync strategies. Being able to reference namespace-scoped strategies in other namespaces could be useful, since they wouldn't require cluster-scoped permissions to apply. 🤔

In general I believe k8s leans toward the former approach for security best-practices with managing multi-tenant clusters.

[alexymantha]

Just to make sure I'm understanding properly: you're suggesting something similar to ClusterRole/Role where we would have a cluster-scoped ClusterSyncStrategy and a namespaced SyncStrategy?

If so, I think it you're right, it would be more aligned with what k8s is already doing.

[wmgroot]

Yes, exactly. This suggestion was provided by the skyscanner folks that built the original concept that Progressive Sync is based on.

https://github.com/Skyscanner/applicationset-progressive-sync

[gordonswing]

Well-demanded feature for us!

[uri-lightblocks]

Looking forward to have it soon

[dijareoracle]

Would be great if this got implemented as we need this exactly in our setup

[agaudreault]

I think this might be superseded in some part by #17755 and #17506, but I see how it would still be desirable to have a rolling sync with applications that have a large number of clusters.