1. Proposed title of this feature request

Allow openshift-controller-manager-operator to omit certain labels and/or annotations when copying Configmaps from one namespace to another{}

This is not a gitops specific issue as it can be workaround already in a gitops way. This feature request aims to change the OpenShift Controller Manager Operator logic  while configuring custom PKI as documented in official doc

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

When configuring a custom PKI as in official doc and deploying the same using GitOps (Argo CD), the trustedCA(eg:custom-ca) ConfigMap is correctly created in the "openshift-config" namespace and referenced in the "Proxy" custom resource. As expected, the "OpenShift Controller Manager Operator" automatically copies this ConfigMap to the "openshift-controller-manager" namespace as "openshift-user-ca" configmap.

However, during this copy process, all labels and annotations, including Argo CD-specific metadata (e.g. "app.kubernetes.io/instance") are preserved in the copied ConfigMap.

This causes Argo CD to mistakenly interpret the duplicated ConfigMap in the "openshift-controller-manager" namespace as an "out-of-sync" or orphaned resource and attempts to prune it, resulting in unintended behavior.

While the issue can be worked around using "argocd.argoproj.io/compare-options: IgnoreExtraneous", resource exclusions or "annotation + label" tracking method, we propose enhancing the operator logic to strip or avoid copying specific labels(eg: gitops specific) and annotations when creating the destination configmap(eg:  "openshift-user-ca" ConfigMap).

How Argo CD shows derived resources in the resource tree? Is there any command or annotation or something else?
Yes! This is a default 'app.kubernetes.io/instance' label.

This is not a gitops specific issue as it can be workaround already in a gitops way. This feature request aims to changing the OpenShift Controller Manager Operator logic  while configuring custom PKI as documented in official doc

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

Customer wants to use Openshift GitOps operator (Argo CD) to manage cluster configuration(eg Proxy configuration).  They would like to avoid a clash between openshift-controller-manager and Argo CD both trying to manage the destination configmap "openshift-user-ca" in namespace "openshift-controller-manager"

Goals 

• Prevent false-positive sync issues and unintentional pruning by Argo CD.
• Ensure cleaner separation between operator-managed and GitOps-managed resources.
• Improve user experience and stability in GitOps-driven OpenShift environments.
• Avoid a clash between openshift-controller-manager and Argo CD both trying to manage the destination configmap "openshift-user-ca" in namespace "openshift-controller-manager"

4. List any affected packages or components.

Openshift-controller-manager