Description of problem: Using ArgoCD to configure authentication.
We noticed that the secrets mentioned in the OAuth configuration are copied from the openshift-config namespace to the openshift-authentication namespace. This copy also contains the kubernetes.io/instance label, which makes ArgoCD think the copied secret is managed by itself, as well, and it shows this as 'out of sync'.
The situation gets worse, when auto-heal and pruning is enabled. This makes ArgoCD remove these secrets, followed by the operator, adding them back, after which ArgoCD removes them again, and so on.
As workaround we added "argocd.argoproj.io/compare-options: IgnoreExtraneous" annotation.
To build further on my example, I defined the secret as follows:
- name: local_accounts
- name: Active_Directory
The annotations are copied to the corresponding secret which itself gets ignored. This allows me to activate the self-heal with prune option, without having the loop effect.
This solves the issue only partly, because now the secret itself (not the copy in openshift-authentication) will still not be pruned when I remove it from my configuration. Their existence will be ignored by the annotation.
While this seems to be a valid (partial) workaround,
Make ArgoCD ignore the namespaces that already contain managed payloads, we can't and won't be special-casing every project out there. If it's not possible to make ArgoCD ignore namespaces, make them add that ability.
From your comment, I understand that copying the labels and annotations from the source secret to the destination is a design decision.
What is the use case for copying that? Does the authentication operator accept any special labels or annotations in the secrets to fine tune its behaviour?
For reference, related argocd issue.
Moving closer to the team dealing with APIs.
As part of the migration of all OpenShift bugs to Red Hat Jira, we are evaluating all bugs which will result in some stale issues or those without high or urgent priority to be closed. If you believe this bug still requires engineering resolution, we kindly ask you to follow this link and continue working with us in Jira by recreating the issue and providing the necessary information. Also, please provide the link to the original Bugzilla in the description.
To create an issue, follow this link: