[occm] Shared loadbalancer should not be renamed.

[kratisto]

Hello,

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug

While testing shared loadbalancers, i think i discovered a regression since this PR.

A shared loadbalancer is renamed due to this if. What happens here is :

We enter the ensureOctaviaLoadBalancer function as clusterb with a shared loadbalancer named : kube_service_clustera_kns_fakeservice

At the end we can see the cluster has been renamed : kube_service_clusterb_kns_fakeservice.

And we have the event : Warning LoadBalancerRename Loadbalancer fakeloadbalancerid has a name of kube_service_clustera_kns_fakeservice with incorrect cluster-name component. Renaming it to kube_service_clusterb_kns_fakeservice.

The tags has been changed too : ["kube_service_clustera_kns_fakeservice","clustera","kube_service_clusterb_kns_fakeservice"] become ["kube_service_clusterb_kns_fakeservice","clustera","kube_service_clusterb_kns_fakeservice"]

I created a test that reproduce the regression.

Didn't test if it's the case , but i suspect that if we launch a third time as clusterc , the shared loadbalancer will be renamed again. So the ownership will be for the last runner of ensureOctaviaLoadBalancer

[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

[kratisto]

/remove-lifecycle stale

[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

[kratisto]

/remove-lifecycle stale

[mxm-tr]

Yep, this prevents LBs from being shared between multiple clusters

[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

[mxm-tr]

/remove-lifecycle rotten

[mxm-tr]

/remove-lifecycle stale