applicationset-progressive-sync
applicationset-progressive-sync copied to clipboard
Will progressive sync controller support multi environment environment promotion?
Hi Team, you are doing awesome job here!
I've opened this issue to ask you a question whether you are planning to support following environment promotion scenario: App is running in multiple clusters per environment (let's say 2 dev, 2 preprod, 2 prod) Once there is an update to the app that should be rolled into those clusters:
- it is being rolled out into both dev clusters
- [environment promotion] if app was rolled out successfully to both dev clusters then app will be rolled out into preprod clusters, otherwise whole pipeline fails and no sync will be done in preprod clusters
- [environment promotion] same as 2 but from preprod to prod
Hey @surmabck sorry for the late reply but I missed the notification.
I think we will be able to support your use case out-of-the-box. Imagine that you have all your clusters in ArgoCD and you have labelled them with env: dev
, env: preprod
and env: prod
.
Then if you write a ProgressiveSync similar to
apiVersion: argoproj.skyscanner.net/v1alpha1
kind: ProgressiveSync
metadata:
name: myprogressiverollout
namespace: argocd
spec:
# a reference to the target ApplicationSet
sourceRef:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
name: myappset
# the rollout steps
stages:
# human friendly name
- name: two clusters in dev
maxParallel: 2
maxTargets: 2
targets:
clusters:
selector:
matchLabels:
env: dev
- name: two clusters in preprod
maxParallel: 2
maxTargets: 2
targets:
clusters:
selector:
matchLabels:
env: preprod
- name: two clusters in prod
maxParallel: 1
maxTargets: 2
targets:
clusters:
selector:
matchLabels:
env: prod
This will update the 2 dev clusters in parallel. If they are successful it will then move to the preprod ones and finally it will sync the 2 prod ones but one at the time. If any of the stage fails the ProgressiveSync will stop.
Hey @maruina, Thx for the info. This is what I thought, but couldn't find any documentation to prove it. FYI, right now we have developed our own synchronization mechanism based on separate git commits, but we are looking forward to try this controller once it's there in GA. I keep my fingers crossed for you 👍
I think you may close the issue now.
This is what I thought, but couldn't find any documentation to prove it.
Yes, there is a lot of work we still need to do here :) We need to fix a couple of issue around the scheduling and then we will have a testable alpha version. I know it's far from GA but you should be able to test it with a non critical workload :)
interesting that it would manage both progressive rollout and promotion. In my case, before promoting, I need to perform so QA/tests prior to granting the GO... im not sure how it would fit in the middle but that d be great. Maybe Argo-wf would be a better fit instead... I will check. Also I was wondering how things would be made visible for end users to follow the "flow"...