Can Argo Manage its own Helm Release? Should it? #2661
Replies: 2 comments
-
This would also be useful to manage labels on the argocd namespace, which I similarly have to do with patched manifests & serversideapply=True, for syncing clusterexternalsecrets. |
Beta Was this translation helpful? Give feedback.
-
@charles-horel-rogers - Hi I would say it's quite common practice in community where Argo CD starts to self-manage itself after initial installation. The only downside that you might encounter is if something happens to application or applicationset controller. At that point you might need to manually fix the deployment with |
Beta Was this translation helpful? Give feedback.
-
It would be nice if I could bootstrap ArgoCD on a kubernetes cluster, and then define an application that manages the ArgoCD helm release.
Currently if I want to make changes to RBAC or the ArgoCD config maps declaratively using Argo, I have a couple of options. I can just patch the CM manually using argo (snippet below). I also have the option of re-running my helm bootstrap process manually with modified values.
I am wondering if managing this by having Argo manage its own helm release after bootstrapping is a better idea, or a much worse idea. That way I can push a change to version control and update TLS trust on the argocd-cm, or add policy mappings to policy.csv. I noticed that argo deployed helm releases don't show up when you run helm list, it looks like it's managing releases internally to argo and deploying manifests to the cluster only.
Has anyone tried this? My gut tells me it's not a great idea, but I figured I'd ask about my current approach and see if there are any other alternatives that are preferable.
Beta Was this translation helpful? Give feedback.
All reactions