Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-7018

SourceNamespaces with long project name causing Reconciler error: must be no more than 63 characters

XMLWordPrintable

    • 5
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      Before this update, the ArgoCD Operator failed to create RoleBindings when using long namespace names in sourceNamespaces due to Kubernetes label validation errors. The issue occurred because Kubernetes labels have a 63-character limit, but the operator was attempting to use the full namespace name as a label value, causing reconciliation failures with "must be no more than 63 characters" errors. With this update, this issue is fixed by implementing a truncateWithHash function that intelligently truncates long names to fit within the 63-character limit while appending a deterministic hash suffix to maintain uniqueness. Now, RoleBindings can be successfully created even when sourceNamespaces contain long namespace names, ensuring that the operator can properly reconcile resources regardless of namespace name length while maintaining unique identification through hash-based suffixes.

      The fix implements a truncateWithHash function that:

      1. Truncates long names to fit within the 63-character limit
      2. Appends a deterministic hash suffix to maintain uniqueness
      3. Ensures RoleBinding names remain unique even when truncated

      Show
      Before this update, the ArgoCD Operator failed to create RoleBindings when using long namespace names in sourceNamespaces due to Kubernetes label validation errors. The issue occurred because Kubernetes labels have a 63-character limit, but the operator was attempting to use the full namespace name as a label value, causing reconciliation failures with "must be no more than 63 characters" errors. With this update, this issue is fixed by implementing a truncateWithHash function that intelligently truncates long names to fit within the 63-character limit while appending a deterministic hash suffix to maintain uniqueness. Now, RoleBindings can be successfully created even when sourceNamespaces contain long namespace names, ensuring that the operator can properly reconcile resources regardless of namespace name length while maintaining unique identification through hash-based suffixes. The fix implements a truncateWithHash function that: 1. Truncates long names to fit within the 63-character limit 2. Appends a deterministic hash suffix to maintain uniqueness 3. Ensures RoleBinding names remain unique even when truncated
    • GitOps Tangerine Sprint 17, GitOps Tangerine Sprint 18

      Description of Problem

      • SourceNamespaces with long project name causing Reconciler error
          error reconciling roleBinding for "argocd-server": RoleBinding.rbac.authorization.k8s.io "<instance-name>_<project-name>" is invalid: metadata.labels: Invalid value: "<instance-name>_<project-name>": must be no more than 63 characters

      Reproducibility

      • Always

      Prerequisites/Environment

      • RHOCP `v4.14.33`
      • GitOps 1.16

      Steps to Reproduce

      • Update ArgoCD CR, add SourceNamespaces with value like `grp-*`
      • Create a project prefix `grp-` with a long name so that the generated rolebinding label would be >63 characters. example `grp-bk-time-deposit-servicing-activity-topic-streaming`
      • Check operator pod logs:
      error reconciling roleBinding for "argocd-server": RoleBinding.rbac.authorization.k8s.io "<instance-name>_<project-name>" is invalid: metadata.labels: Invalid value: "<instance-name>_<project-name>": must be no more than 63 characters

      Expected Results

      • SourceNamespace creates role and rolebinding successfully.

      Actual Results

      • Rolebinding creation failed with error.

      Problem Analysis

      • The label issue itself is Kubernetes-centric in a manner, since k8s has a limit on characters for label keys and values. 

      Root Cause

      • Every resource gets a label of kubernetes with value same as resource name. 

      Workaround (If Possible)

      • use short project name

      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.

              rh-ee-atali Atif Ali
              rhn-support-sburhade Satyam Burhade
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: