Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-26317

[2.15] Upgrading ACM 2.13.4 to 2.14.0 cause siteConfig pod container kube-rbac-proxy to get in error

XMLWordPrintable

    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • False
    • Installer Sprint 2025-72
    • Moderate
    • None

      Description of problem:

      I have installed ACM 2.13.4 (In fact it was upgraded fom 2.11.8) , then enable SiteConfig plugin.

      When I upgraded to ACM 2.14.0 I start seeing error siteconfig-controller-manager- Pod failing and cannot start container kube-rbac-proxy.

       

      {{oc logs -n open-cluster-management -c kube-rbac-proxy siteconfig-controller-manager-748d755dc6-92rth }}
      I0815 13:41:00.305951       1 main.go:176] Valid token audiences:
      I0815 13:41:00.306051       1 main.go:252] Generating self signed cert as no cert is provided
      I0815 13:41:00.811035       1 main.go:302] Starting TCP socket on 0.0.0.0:8443
      F0815 13:41:00.811232 1 main.go:305] failed to listen on secure address: listen tcp 0.0.0.0:8443: bind: address already in use

      Version-Release number of selected component (if applicable): 2.14.0

      How reproducible: always

      Steps to Reproduce:

      1.  install ACM 2.13.4 ; start with siteConfig-V1 (kustomize/SiteConfig installation ); 
      2. then enable siteConfig-v2 by enabling siteConfig plugin in ACM mch. (Procedure it to be found) ... I am not sure if you enable directly siteConfig Plugin without
      3. upgrade to 2.14.0 
      4. I am not sure if you have to start with siteConfig-v1 and install spokes with siteConfig-v1 then migrate all to siteConfig-v2? or you just enable siteConfig-v2 on hub and would cause the same issue.

      you can see it by doing this too:

      oc -n open-cluster-management debug deploy/siteconfig-controller-manager
      Defaulting container name to manager.
      Use 'oc describe pod/siteconfig-controller-manager-debug-n2wkl -n open-cluster-management' to see all of the containers in this pod.Warning: spec.containers[1].ports[0]: duplicate port definition with spec.containers[0].ports[1]

      Actual results:

      siteconfig-controller-manager- pod fails to start: kube-rbac-proxy fails with the above error  

       

      Expected results: the pod must start with errors. Apprently the kube-rbac-proxy should not be there at all. It should be removed once upgrade happens

      Additional info:

      I did workaround to make it work:

      ----- oc edit deploy/siteconfig-controller-manager

            - args:
              - --secure-listen-address=0.0.0.0:7443
              - --upstream=http://127.0.0.1:8080/
              - --logtostderr=true
              - --v=10
              image: registry.redhat.io/rhacm2/kube-rbac-proxy-rhel9@sha256:3028d011e7b88dd9597821128275f606fdba639e5b83e4e6a8783fa2616cba6f
              imagePullPolicy: IfNotPresent
              name: kube-rbac-proxy
              ports:
              - containerPort: 7443
                name: https
                protocol: TCP

      [ instead of port 8443, replaced with 7443 in both secure list address and container's Port ]

      -------------------------------------------------------------------------------------------------------
      QE Hand Off Template (fill out when moving to Review) 11/18/25:

      Summary of the Work:
      What was implemented or fixed? Include a brief description of the problem (if applicable) and how it was addressed.
      e.g., "Updated the UI to show validation errors for the form. The previous implementation did not surface backend validation issues."

      Key Areas to Verify:

      1. What functionality should QE focus on? List what was tested or what is most important to validate.
      2. Ensure the new validation messages appear for required fields
      3. Confirm the workflow still completes as expected after validation fixes
      4. Any edge cases or high-risk areas touched by the change

      Fix or Feature Availability:
      When will this be available in a build?
      Code merged on: YYYY-MM-DD
      Expected downstream build tag (if known): example-build-tag
      (Optional) Related PR(s): Link

              dbennett@redhat.com Disaiah Bennett
              lhalleb@redhat.com Lazhar Halleb
              Matthew Smigielski Matthew Smigielski
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: