-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
5
-
False
-
-
False
-
-
-
GitOps Crimson Sprint 21, GitOps Crimson Sprint 23
Description of Problem
When apps in any namespace is enabled, app.kubernetes.io/name label for the RBAC resources which gets created are expected to have the name of the argocd instance it is managed by. However, with rolebinding, this is not the case and gets the value of the rolebinding name instead.
Here, example-argocd is the argocd instance name, created in central-argocd ns with test-1-24-custom added as one of the sourceNamespaces in argocd CR
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: "2025-07-24T06:26:26Z" labels: app.kubernetes.io/managed-by: example-argocd app.kubernetes.io/name: example-argocd app.kubernetes.io/part-of: argocd name: example-argocd_test-1-24-custom . . . --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: annotations: argocds.argoproj.io/name: example-argocd argocds.argoproj.io/namespace: central-argocd creationTimestamp: "2025-07-24T06:26:26Z" labels: app.kubernetes.io/managed-by: example-argocd app.kubernetes.io/name: example-argocd_test-1-24-custom app.kubernetes.io/part-of: argocd name: example-argocd_test-1-24-custom . .
Additional Info
Not related but - There are no annotations in role
Problem Reproduction
- Enable apps in any namespace and check the RBAC created in managed ns
Reproducibility
- Always
Prerequisites/Environment
- Openshift gitops operator version > 1.13 in a regular OCP
Steps to Reproduce
- Create a cluster scoped argocd instance and add a test namespace to the sourceNamespaces field in argocd cr
- Check the newly created application controller role and rolebinding for app.kubernetes.io/name label in test namespace
Expected Results
- app.kubernetes.io/name should have the same name as argocd instance the ns is managed by
Actual Results
- app.kubernetes.io/name label has the name of the rolebinding as its value
- Rolebinding's app.kubernetes.io/name label value is different from Role
Problem Analysis
- <Completed by engineering team as part of the triage/refinement process>
Root Cause
- <What is the root cause of the problem? Or, why is it not a bug?>
Workaround (If Possible)
- <Are there any workarounds we can provide to the customers?>
Fix Approaches
- <If we decide to fix this bug, how will we do it?>
Acceptance Criteria
- ...
Definition of Done
- Code Complete:
- All code has been written, reviewed, and approved.
- Tested:
- Unit tests have been written and passed.
- Ensure code coverage is not reduced with the changes.
- Integration tests have been automated.
- System tests have been conducted, and all critical bugs have been fixed.
- Tested and merged on OpenShift either upstream or downstream on a local build.
- Documentation:
- User documentation or release notes have been written (if applicable).
- Build:
- Code has been successfully built and integrated into the main repository / project.
- Midstream changes (if applicable) are done, reviewed, approved and merged.
- Review:
- Code has been peer-reviewed and meets coding standards.
- All acceptance criteria defined in the user story have been met.
- Tested by reviewer on OpenShift.
- Deployment:
- The feature has been deployed on OpenShift cluster for testing.