Created attachment 1956841 [details] appset Description of problem (please be detailed as possible and provide log snippests): When an application set based app is deleted its placement is not getting deleted. oc get placement -n openshift-gitops | grep b-app-12 b-app-12-placement True AllDecisionsScheduled 1 "Remove ApplicationSet related resources" was checked while initiating the delete. (see screenshot) Version of all relevant components (if applicable): ocp: 4.13.0-0.nightly-2023-04-01-062001 odf: 4.13.0-124 acm: 2.7.2(GA) Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? no Is there any workaround available to the best of your knowledge? yes, delete the respective apps placement manually Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 2 Can this issue reproducible? 3/3 Can this issue reproduce from the UI? yes If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. Configure 3 OCP 4.13 clusters. hub/acm, c1 and c2. 2. Configure MDR 3. Deploy Appset based apps on c1. 4. Delete an appset application with "Remove ApplicationSet related resources" box checked. (screenshot) Actual results: Application is deleted in c1 but the 'placement' resource of the app persists on hub. Expected results: If "Remove ApplicationSet related resources" is selected while deleting, the application and all its resources must be deleted Additional info: If the app placement is not deleted manually, there will be an error while creating new appset based app with same name. Like: <app-name>-placement already exists.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenShift Data Foundation 4.13.0 enhancement and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:3742