-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about this pattern and ordered application set #57
Comments
Hi @alex-treebeard thank you opening the issue with your question On the ordering for applicationset is something we are working with @christianh814 Adding syncwaves it each application set in order but from one application set to the other it doesn't wait for the app to be healhty. This is something we plan to address with progresive sync on each application set. Right now I have a repo I"m experimenting and having syncwave and increasing the delay from 2s to 30s is enough time to guaranteed that the addon/helmchart is ready before starting the next one
And adding the sync wave annotation
|
About your comment
The design of the pattern is to make the template git repo work out of the box for centralize hub-spoke, that you have one argocd deploying to multiple clusters. With App of Apps you loose a lot of benefits of using ApplicationSets, we are kind of doing App or Apps but with ApplicationSet in the middle. This way the team starts to think on using ApplicationSets from day 1. In the backlog there is a request to create a helm chart that renders the applicationsets this would gitops-bridge-dev/gitops-bridge-argocd-control-plane-template#40 |
We have a Slack channel in CNCF |
There is a Issue and PR in the works that adds the dependsOn on Applications that should help with ordering for apps (ie across clusters) |
About passing thru cluster secret vs. helm boostrap, there are benefits that you can put this data in cluster usig argo api-server, or other IaC (Pulumi, Crossplane, etc) don't have to worry on passing the values to a helm chart (this will make everyone have their own version of app or apps helm chart) and just put the minimum metadata on the cluster without worrying how the bootstrap is done, they responsibility as IaC is to create cluster and create cluster secret, that's it, for spoke cluters there is no helm chart to boostrap, just registering a remote cluster all the addons start deploying to the remote cluster (not running argo) |
thanks for this clarification...joined slack! |
Hi @csantanapr, thanks a lot for this org -- I'm trying out the gitops bridge pattern for bootstrapping Kubeflow (see tf module, and fork of your control plane.
I can see that this stuff is quite bleeding edge so I'm trying to find practical workarounds in places.
One of the first issues I've noticed is that I'd like these applicationsets to sync in order (i.e. so that istio webhook works before we try creating pods in the mesh). If sync waves doesn't work reliably I may enforce dependencies with terraform instead.
Are you aware of any inherent argo limitations here? or do you have any other pointers to those interested in feeding terraform outputs into K8s systems in this way?
Thanks again!
edit:
Another thing I've been wondering is: What is the benefit of passing cluster variables to argo via the cluster secret, as opposed to having some helm-based App of Apps, where cluster variables can be passed to child apps via helm values?
The text was updated successfully, but these errors were encountered: