Epic Goal

Design and implement the behavior for the ConfigurationPolicy pruneObjectBehavior option when the namespaceSelector or objectDefinition is modified to apply to different objects.

Should it only delete the objects that the policy handles at the time of deletion, which is the behavior in 2.6? Should it delete all objects the policy has ever handled at policy deletion? Should it delete the objects that no longer apply right after a change to the namespaceSelector or objectDefinition?

The behavior cannot change with the current options, but adding additional options to cover this is okay, if we choose to change this at all.

Why is this important?

The current behavior is different than ArgoCD, which may be the assumption that customers have and desire. There is also benefit to providing a similar functionality to ArgoCD, where the objects that the policy no longer handles after a modification are deleted/pruned.

Scenarios

1. As an ACM policy maintainer, I set pruneObjectBehavior to DeleteAll or DeleteIfCreated to a policy that creates a ConfigMap. I then rename the ConfigMap in the policy and want the old ConfigMap to be automatically deleted.
2. As an ACM policy maintainer, I set pruneObjectBehavior to DeleteAll or DeleteIfCreated to a policy that creates a ConfigMap in several namespaces using the namespaceSelector field. I then change the namespaceSelector in the policy and want the ConfigMaps in the old namespaces to be automatically deleted.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>