Open Aransh opened 1 year ago
I suggest we add an annotation with the parent applicationset name + namespace that can be checked before the controller updates an application. The annotation could also be used to generate a list of child applications from the cli (similar to #13456 and the follow-up #15423).
Happy to contribute something.
also encountered the issue and i had accidentally removed our production application 😭
See #16883
Also experienced this, mistakenly called two application sets the same name and produced to delete a production application.
Are there any eyes on the PR above getting merged?
This happened to us as well with duplicate ApplicationSet names. We deployed some ApplicationSets that conflicted with others, which resulted in creation of the new set with warnings on both old and new, but on each refresh it deleted everything and restarted it all. It managed to restart everything twice before I managed to fix the naming.
This was production.
It seems a little destructive to destroy everything the second a duplicate application set is deployed, instead of warning us only.
Describe the bug
If an app is generated via an ApplicationSet (list generator in my case), seems ArgoCD does not validate that a duplicate app with the same exact name already exists. In our architecture we use a single ArgoCD server to manage several clusters, due to mistakes made by both devs and devops, we already had several incidents where due to using the same exact name of an app on the same cluster, the app will be practically installed twice, with both installations intermittently overwriting each other. From what I've seen, if you create a duplicate app without an applicationset, it will refuse to sync and throw an error (which is great), but if done through an application set:
To Reproduce
Create an applicationSet, use a list generator to create an app Create a second applicationSet, and use a list generator to create an app with the same name, but different configuration Watch as they endlessly fight over control Try to remove one, and see how the resources experience a downtime
Not sure if relevant, but in our case this has happened with applicationSets deployed by "app of apps", on 2 separate branches.
Expected behavior
The applicationSet refuses to sync, stating this argo server already contains an app with this generated name
Version