1. Proposed title of this feature request

Improvement of the non-cascading (orphan) application resource deletion in ArgoCD from the application tree when the App of Apps pattern is used

2. What is the nature and description of the request?

When using the App-Of-Apps pattern [1] with ArgoCD, the child applications are resources of the parent application. Let’s assume that the parent application does not have sync options defined, i.e., auto-sync and self-heal are disabled for the parent application.

When deleting an application as a resource of the parent application from the parent application tree, it is possible to flag the non-cascading option. In this case, the behavior is different from deleting the same application from the application list with the non-cascading option, specifically:

• From the list of Applications or the Application’s detail view - NON-CASCADING DELETE: ArgoCD treats the resource as an Application. The managed resources are defined by either a label or an annotation. In this context, by checking the non-cascading option, ArgoCD will remove the finalizer and delete the Application instantly without deleting managed resources, as expected.
• From the resource tree - NON-CASCADING (ORPHAN) DELETE: ArgoCD treats resources without context. Therefore, ArgoCD is not considering that resource as an application, and the deletion options follow: https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion.
  As a consequence, if the finalizer is still defined in the live resource, the child application and all its resources are deleted even when checking the non-cascading option. The user's (the customer's) expectation is to have the application’s managed resources preserved transparently when checking the non-cascading option, even if the finalizer is still defined in the live resource, as in the previous case.

The request is to modify the behavior of non-cascading delete from the application resource tree in case the deleted resource is an application in order to prevent the user/customer from accidentally removing the child application and all its managed resources.

The related documentation should be updated accordingly because at the moment, this behavior is not clearly described in the App of Apps pattern ArgoCD documentation.

[1] https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#app-of-apps

3. Why does the customer need this? (List the business requirements here)

The NON-CASCADING (ORPHAN) DELETE and NON-CASCADING DELETE options with their messages are generating confusion, so users are prone to error. Specifically, it happened that a user/customer deleted a child application from the application resource tree, checking the non-cascading option because they wanted the child application resources to be preserved, and they caused a major incident in production because the child application and all its resources were deleted anyway.

Also, the documentation does not clearly describe this scenario and the different observed behaviors, so it should be improved accordingly to underline the difference between the non-cascading application deletion from the parent application tree versus from the application list.

4. List any affected packages or components.

OpenShift-GitOps ArgoCD UI and ArgoCD documentation