Upgrading cluster-api-operator via Helm causes provider namespaces to be removed

[matofeder]

What steps did you take and what happened:

1. Install cluster-api-operator in the Kubernetes cluster using Helm, providing a values.yaml file that also deploys two providers:

addon:
  helm:
    namespace: caaph-system
    version: v0.3.1
core:
  cluster-api:
    namespace: capi-system
    version: v1.10.2

2. Upgrade cluster-api-operator using the same values.yaml file (with no changes)

3. During the upgrade, the namespaces of the providers are removed and then recreated

What did you expect to happen:

Do not recreate the provider namespace

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Steps to reproduce (using kind):

$ kind create cluster
$ helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set installCRDs=true

$ cat values.yaml    
addon:
  helm:
    namespace: caaph-system
    version: v0.3.1
core:
  cluster-api:
    namespace: capi-system
    version: v1.10.2

$ helm upgrade --install capi-operator capi-operator/cluster-api-operator --create-namespace -n capi-operator-system --wait --timeout 90s -f values.yaml

If you hit the helm upgrade --install capi-operator capi-operator/cluster-api-operator --create-namespace -n capi-operator-system --wait --timeout 90s -f values.yaml again without any values change you can observe the following:

$ kubectl get ns --watch

NAME                   STATUS   AGE
caaph-system           Active   88s
capi-operator-system   Active   4m44s
capi-system            Active   71s
cert-manager           Active   5m44s
default                Active   6m51s
kube-node-lease        Active   6m51s
kube-public            Active   6m51s
kube-system            Active   6m51s
local-path-storage     Active   6m47s
caaph-system           Terminating   100s
caaph-system           Terminating   105s
caaph-system           Terminating   110s
caaph-system           Terminating   115s
caaph-system           Terminating   115s
caaph-system           Active        0s
capi-system            Terminating   99s
capi-system            Terminating   104s
capi-system            Terminating   109s
capi-system            Terminating   114s
capi-system            Terminating   114s
capi-system            Active        0s

Environment:

• Cluster-api-operator version: v0.21.0
• Cluster-api version: v1.10.2
• KIND version: v0.29.0
• Kubernetes version: (use kubectl version): v1.33.1
• OS (e.g. from /etc/os-release): Ubuntu 25.04

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api-operator/labels?q=area for the list of labels]

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[matofeder]

probably related to #562

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten