When I use an app-of-apps pattern, and one of the Applications inside it is removed, I am notified in the UI that the app is out of sync, waiting to be pruned, with confirmation of the prune via checkbox.
When I use an appset, and one of the applications inside it is removed (e.g. by a change to a selector from git), by default the child app is summarily removed. If I change the appset controller policy to create-update to remove its ability to summarily delete items, then the child app lingers and I need to remove it manually.
Ideally, in the default configuration, instead of summarily deleting the child app, it should indicate that the app is waiting to be pruned and allow me to sync the appset with prune enabled, just like anything else.
Motivation
I am using appsets to fan out across a bunch of dependent clusters. Not all apps are present in all clusters, though, and we control that by setting a flag in a yaml file-per-cluster in git. These files are read by a git generator and used in a selector.
Sometimes during a rollout (or rollback) I need to alter the flag to enable/disable the app. In the case of an enable, I still have to sync the creation of the application, and I get to look at the diff before I do; in the case of a disable, I would love to have the same ability to inspect before prune.
Proposal
Rework appset delete behavior to surface prunes into the standard argo sync/prune model.
Summary
When I use an app-of-apps pattern, and one of the Applications inside it is removed, I am notified in the UI that the app is out of sync, waiting to be pruned, with confirmation of the prune via checkbox.
When I use an appset, and one of the applications inside it is removed (e.g. by a change to a selector from git), by default the child app is summarily removed. If I change the appset controller policy to
create-updateto remove its ability to summarily delete items, then the child app lingers and I need to remove it manually.Ideally, in the default configuration, instead of summarily deleting the child app, it should indicate that the app is waiting to be pruned and allow me to sync the appset with prune enabled, just like anything else.
Motivation
I am using appsets to fan out across a bunch of dependent clusters. Not all apps are present in all clusters, though, and we control that by setting a flag in a yaml file-per-cluster in git. These files are read by a git generator and used in a selector.
Sometimes during a rollout (or rollback) I need to alter the flag to enable/disable the app. In the case of an enable, I still have to sync the creation of the application, and I get to look at the diff before I do; in the case of a disable, I would love to have the same ability to inspect before prune.
Proposal
Rework appset delete behavior to surface prunes into the standard argo sync/prune model.