Skip to content

[occm] Tag load balancers with cluster identity to prevent name collisions - #3103

Open
enginrect wants to merge 7 commits into
kubernetes:masterfrom
enginrect:occm-cluster-id-tag
Open

[occm] Tag load balancers with cluster identity to prevent name collisions#3103
enginrect wants to merge 7 commits into
kubernetes:masterfrom
enginrect:occm-cluster-id-tag

Conversation

@enginrect

@enginrect enginrect commented Apr 30, 2026

Copy link
Copy Markdown

What this PR does / why we need it:

OCCM identifies an existing Octavia load balancer for a Service by name on
the first reconcile (via getLoadbalancerByName). The name format
kube_service_<cluster-name>_<namespace>_<service> defaults to a
<cluster-name> of kubernetes, so two Kubernetes clusters in the same
OpenStack project that happen to use the default cluster-name and have
Services with identical namespace/name produce identical load balancer
names. Octavia does not enforce uniqueness of names, so OCCM in cluster B
ends up adopting and overwriting cluster A's load balancer. This has been
reported repeatedly (see #2241, #2571, #2624) and the standing guidance
"set a unique --cluster-name" is correct but does not actually defend
against the failure mode.

This PR adds a stable Kubernetes cluster identifier - the UID of the
kube-system namespace - as a load balancer tag of the form
kube_cluster_id_<uid>. Lookup behaviour:

  • LBs that carry the matching kube_cluster_id_<our-uid> tag are kept.
  • LBs that carry no kube_cluster_id_* tag fall back to the legacy
    behaviour (preserves existing deployments and externally-created LBs).
  • LBs that carry only foreign kube_cluster_id_* tags are treated as
    NotFound, with a warning. OCCM will then create its own load balancer
    rather than overwriting one that belongs to another cluster.

The cluster UID is read once at controller-manager start-up. If the
lookup fails (RBAC denial, missing namespace, etc.) the safeguard is
disabled and OCCM falls back to the legacy name-based behaviour, so the
change is strictly additive. Pre-existing load balancers also gain the
kube_cluster_id_* tag during the next reconciliation.

Which issue this PR fixes(if applicable):
fixes #3102

Special notes for reviewers:

  • Backward compatibility:
    • Load balancers without any kube_cluster_id_* tag keep the previous
      behaviour. They are tagged on the next successful reconcile.
    • Load balancers looked up via the existing
      loadbalancer.openstack.org/load-balancer-id annotation (i.e. on
      every reconcile after the first one) go through GetLoadbalancerByID,
      which is unaffected.
  • New RBAC: get on namespaces is added to both the manifest
    ClusterRole (manifests/controller-manager/cloud-controller-manager-roles.yaml)
    and the helm chart (charts/openstack-cloud-controller-manager/templates/clusterrole.yaml).
    If the verb is unavailable the safeguard simply degrades to the legacy
    behaviour with a warning log; OCCM does not refuse to start.
  • Octavia API >= v2.5 (Stein) is required for the tag feature. This is
    already gated by svcConf.supportLBTags and behaves as before on older
    clouds.
  • New unit tests:
    • TestFilterLoadBalancersByClusterID covers the matching, legacy,
      foreign-only, and mixed cases.
    • TestFetchClusterUID covers happy path and graceful degradation
      (missing namespace, forbidden) with a fake clientset.

How to verify manually:

go test ./pkg/openstack/...

A reproduction of the original failure mode (two clusters in the same
project, same --cluster-name, same Service ns/name) is described in
#3102.

Release note:

[openstack-cloud-controller-manager] Octavia load balancers are now tagged with `kube_cluster_id_<kube-system-uid>` so OCCM no longer adopts a load balancer owned by another cluster in the same OpenStack project. The cloud-controller-manager ClusterRole gains `get` on `namespaces`.

@k8s-ci-robot k8s-ci-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label Apr 30, 2026
@linux-foundation-easycla

linux-foundation-easycla Bot commented Apr 30, 2026

Copy link
Copy Markdown

CLA Signed

The committers listed above are authorized under a signed CLA.

@k8s-ci-robot

Copy link
Copy Markdown
Contributor

Welcome @enginrect!

It looks like this is your first PR to kubernetes/cloud-provider-openstack 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/cloud-provider-openstack has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@k8s-ci-robot

Copy link
Copy Markdown
Contributor

Hi @enginrect. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

@k8s-ci-robot

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kayrus for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Apr 30, 2026
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Apr 30, 2026
@enginrect

Copy link
Copy Markdown
Author

Hi @kayrus @stephenfin @zetaab — first-time contributor here. This PR addresses the long-standing cross-cluster LB collision issue (refs #2241, #2571, #2624) with an additive, backward-compatible kube_cluster_id_<kube-system-uid> tag on Octavia load balancers. Lookups now reject LBs tagged for a different cluster, fall back to legacy behaviour for untagged LBs, and tag pre-existing LBs on the next reconcile. The safeguard degrades gracefully (warning log + legacy behaviour) if the new get on namespaces RBAC is not granted, so the change is strictly additive.

Could one of you take a look and add /ok-to-test when convenient? The failing "Lint Charts" check is unrelated to this PR — it is a pre-existing repository-policy issue on master where the workflow uses unpinned action tags, and it currently fails on every PR.

Thanks!

@enginrect
enginrect force-pushed the occm-cluster-id-tag branch from 123ffe4 to bbf5f4f Compare May 4, 2026 05:35
@k8s-ci-robot k8s-ci-robot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. and removed cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels May 4, 2026
@enginrect
enginrect force-pushed the occm-cluster-id-tag branch 2 times, most recently from 9bb737f to b620ccf Compare May 4, 2026 05:43
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels May 4, 2026
@enginrect

Copy link
Copy Markdown
Author

Quick update: I've rebased on top of master (which now has the SHA-pinned actions from #3100) and bumped the helm chart patch version to 2.35.1 — Lint Charts and EasyCLA are both green now. The PR is still blocked on needs-ok-to-test. @kayrus @stephenfin @zetaab — would one of you mind adding /ok-to-test when convenient? Happy to address review feedback as it comes in.

Comment thread pkg/openstack/openstack.go Outdated
// identifier on OpenStack load balancer tags. May be empty if the lookup
// failed or RBAC does not allow it; in that case OCCM falls back to the
// legacy name-based load balancer identification.
clusterUID string

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clusterUID can be defined only in LoadBalancer struct, please remove it from here.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — thanks! You're absolutely right, that was a cohesion miss on my part. clusterUID is only consumed by the LB code path so it shouldn't pollute the global OpenStack struct. Removed in 56756ea; the field now lives only on LoadBalancer where it belongs.

Comment thread pkg/openstack/openstack.go Outdated
klog.V(1).Info("Claiming to support LoadBalancer")

return &LbaasV2{LoadBalancer{secret, network, lb, os.lbOpts, os.kclient, os.eventRecorder}}, true
return &LbaasV2{LoadBalancer{secret, network, lb, os.lbOpts, os.kclient, os.eventRecorder, os.clusterUID}}, true

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can set clusterUID value here with:

clusterID := fetchClusterUID(os.kclient)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, that's a much cleaner pattern. Fetching lazily inside LoadBalancer() keeps the kube-system namespace lookup out of the global Initialize() path and limits the change to the LB construction site. As a nice side effect, clusters that disable LB now skip the lookup entirely. Done in 56756ea.

Comment thread pkg/openstack/loadbalancer.go Outdated
Comment on lines 192 to 194

@kayrus kayrus May 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can filter by tags using ListOpts.Tags. filterLoadBalancersByClusterID doesn't make sense.
UPD: please ignore this comment

@kayrus kayrus Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see my earlier comment, but I've forgotten my reasoning for changing my mind. Let's add a comment explaining why we're not using API-level tag filtering here. Primarily because we need to log warnings for unmatched tags and for transition period.

That said, I think we should still consider server-side filtering to reduce load on the Octavia API. Do you have any suggestions or concerns about this approach?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think server-side filtering is hard to adopt at this point, mainly because of the legacy LBs. The Octavia tag filter can only express "has tag X", so I don't think a single call can return "LBs tagged with our cluster id, plus LBs with no cluster-id tag at all". To keep the legacy case working we would need a second unfiltered list call as a fallback, and in the common case that doubles the API requests instead of reducing them. Another concern is that we would stop seeing foreign-tagged LBs entirely, so the warning log for the collision case couldn't be emitted.

That said, I think once the tag has been deployed widely enough that the legacy fallback can be dropped, switching to ListOpts.Tags would be a good follow-up optimization. I added a comment in the code explaining this reasoning.

Comment thread pkg/openstack/loadbalancer.go Outdated
// balancer with a matching name that belongs to a different Kubernetes
// cluster (different cluster-id tag). The lookup is treated as NotFound
// so OCCM creates a new load balancer instead of stealing an existing one.
eventLBStolen = "LoadBalancerNameCollision"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it used somewhere?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question — and the honest answer is: no, it's not used anywhere, sorry about the leftover. The original intent was to emit a Warning event via eventRecorder from getLoadbalancerByName when we drop a foreign-tagged LB, but plumbing the event recorder and *v1.Service into that free-standing function felt out of scope for this PR (the existing warning log already covers operator visibility), so I dropped the emission and forgot to remove the constant. Cleaned up in 56756ea.

@enginrect

enginrect commented May 6, 2026

Copy link
Copy Markdown
Author

Thanks for the review @kayrus! Pushed the changes in 56756ea:

  • Dropped the duplicate clusterUID field from the OpenStack struct
    (cohesion fix; thanks for catching this).
  • Moved the kube-system UID lookup into the LoadBalancer() factory
    as a lazy fetch, so it lives in the LB code path only.
  • Removed the unused eventLBStolen constant — explained in the inline
    thread.

go test ./pkg/openstack/... is green locally and the existing checks
(Lint Charts, EasyCLA) are still passing.

@kayrus

kayrus commented May 7, 2026

Copy link
Copy Markdown
Contributor

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 7, 2026
@enginrect

enginrect commented May 7, 2026

Copy link
Copy Markdown
Author

The check job was tripping on SA1019 because the new TestFetchClusterUID was using the deprecated fake.NewSimpleClientset. Pushed bdabd79 swapping it for fake.NewClientset (identical signature, same behaviour for our tests).

Verified locally:

  • go test ./pkg/openstack/... → pass
  • go run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.3.1 run --timeout=20m ./... → 0 issues

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 13, 2026
@enginrect
enginrect force-pushed the occm-cluster-id-tag branch from bdabd79 to efe341d Compare May 13, 2026 23:09
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 13, 2026
@enginrect

Copy link
Copy Markdown
Author

Rebased on top of current master (which now includes release 1.36.0 and Bump github.com/moby/spdystream).

The only conflict was in charts/openstack-cloud-controller-manager/Chart.yaml: master bumped the chart version to 2.36.0 for the 1.36.0 release, while our earlier commit had bumped it from 2.35.0 to 2.35.1. Resolved by setting the chart version to 2.36.1 (patch bump on top of the new baseline). No conflicts in any Go source files — the feature code, tests, and docs rebased cleanly.

Verified locally before pushing:

$ go build ./...                     # OK
$ go vet ./pkg/openstack/...         # OK
$ go test ./pkg/openstack/... -count=1
ok  k8s.io/cloud-provider-openstack/pkg/openstack    0.462s

$ go run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.3.1 run --timeout=20m ./...
0 issues.

All 8 changed files are unchanged in scope from before the rebase — no new code was introduced beyond the version number update. Conflict marker scan (<<<<<<, >>>>>>, =======) across all changed files: 0 matches.

@kayrus — all checks were green before the rebase, and local verification is clean. Would appreciate /lgtm when you have a moment. Thanks!

@JonnyHaystack

Copy link
Copy Markdown

I'm affected by this issue, so I'd like to see this PR merged (assuming it does as described), but I'm not sure what the AI/LLM policy is on this repo and I noticed the replies from @enginrect in this PR are quite obviously LLM generated. Looking at their profile their entire bio is clearly written by LLM too, so one begins to wonder if there's even a human actively controlling this account.

I'd have hoped people would state up front if they're using AI for a contribution to an open-source project, and to what extent they are doing so... This appears on the surface like an agent is handling a lot of this without human interaction, which I would personally say warrants extra scrutiny.

@enginrect

enginrect commented May 28, 2026

Copy link
Copy Markdown
Author

@JonnyHaystack
Thanks for raising this concern.

I want to clarify that this PR comes from a real issue I personally experienced while operating Kubernetes on top of OpenStack using OCCM. The problem described in the issue affected my actual environment, and the patch reflects my own intent and understanding of the behavior I wanted to fix.

Firstly, (True)I did use Cursor assistance for some parts of the coding and for drafting responses. This is my first contribution here, so I may also have been overly detailed or overly polished in my replies. Since I am Korean and English is not my first language, I also used AI assistance to make sure my communication was clear and accurate.

I am still fully responsible for the change, the design decision, the final code, and the discussion in this PR. This is not an autonomous AI-generated contribution.

If maintainers(of this repo) have a specific policy, disclosure requirement, or extra review/security process around AI-assisted contributions, I will follow it and rework on this.

@JonnyHaystack

Copy link
Copy Markdown

Thanks for making that clear 🙂 hoping to see this merged!

@kubernetes-prow kubernetes-prow Bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 29, 2026
@enginrect
enginrect force-pushed the occm-cluster-id-tag branch from efe341d to 7adc9fe Compare July 30, 2026 00:00
@kubernetes-prow

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kayrus for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubernetes-prow kubernetes-prow Bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 30, 2026
enginrect and others added 4 commits July 30, 2026 09:03
…sions

OCCM constructs Octavia load balancer names as
kube_service_<cluster-name>_<namespace>_<service>. When two Kubernetes
clusters share the same OpenStack project and use the same
--cluster-name (default "kubernetes"), services with identical
namespace/name produce identical load balancer names. Octavia does not
enforce uniqueness on load balancer names, so OCCM's first-time
name-based lookup can adopt and overwrite a load balancer that actually
belongs to a different cluster (see issues kubernetes#2241, kubernetes#2571, kubernetes#2624).

This commit adds a stable Kubernetes cluster identifier - the UID of
the kube-system namespace - as a load balancer tag of the form
kube_cluster_id_<uid>. getLoadbalancerByName now ignores load balancers
that carry a cluster-id tag for a different cluster and falls back to
the legacy behaviour for load balancers without any cluster-id tag, so
existing deployments keep working unchanged. Pre-existing load
balancers gain the new tag during the next reconciliation.

The cluster UID is read once at controller-manager start-up via the
kube-system namespace; failure to read it (RBAC denial, missing
namespace) is non-fatal and disables the safeguard, falling back to
legacy name-based lookup. The cloud-controller-manager ClusterRole and
the helm chart gain "get" on namespaces.
- Remove duplicate clusterUID field from the OpenStack struct so the
  identifier lives only on the LoadBalancer struct that actually uses it
  (better cohesion).
- Drop fetchClusterUID() out of Initialize() and call it lazily inside
  the LoadBalancer() factory instead. Clusters that disable LB now skip
  the kube-system namespace lookup entirely, and the change touches only
  the LB construction path.
- Remove the unused eventLBStolen constant. It was a leftover from an
  earlier draft that intended to emit a Warning event from
  getLoadbalancerByName(); plumbing the eventRecorder + *v1.Service into
  that free-standing function felt out of scope, so the emission was
  dropped but the constant was left behind.
The pull-cloud-provider-openstack-check prow job runs golangci-lint
v2.3.1 with staticcheck enabled, which flags fake.NewSimpleClientset as
SA1019 (deprecated). TestFetchClusterUID, added earlier in this PR,
used the deprecated function. Swap it for fake.NewClientset; the
signature is identical (objects ...runtime.Object) and the unit tests
still pass.
An earlier commit in this PR added a "get" on "namespaces" rule to the
Helm chart ClusterRole template. chart-testing requires a version bump
on any chart modification. Bumping the patch version since the change
is additive and backward-compatible.
@enginrect
enginrect force-pushed the occm-cluster-id-tag branch from 7adc9fe to 25e35f2 Compare July 30, 2026 00:04
@enginrect

Copy link
Copy Markdown
Author

@kayrus
I've rebased onto current master again.
BTW, the conflict was with #3149 (LB/listener/pool tags annotations, merged yesterday). Resolved it, so both features coexist.

All checks are green. PTAL when you have time.

Comment thread pkg/openstack/loadbalancer.go Outdated
Review feedback from kayrus: the empty-UID and duplicate checks around
clusterIDTag were repeated at both call sites (LB creation and tag
reconciliation). Replace clusterIDTag with withClusterIDTag, which takes
the tag list and handles those checks itself, following the naming of
the existing withLBNameTag helper. filterLoadBalancersByClusterID now
builds the expected tag directly from clusterIDTagPrefix since it
already guards against an empty UID.

@kayrus kayrus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the patience. See my comments.

UPD: update release note in the initial PR description with less text

Comment on lines +654 to +657
`--cluster-name` on every Kubernetes cluster (see issues
[#2241](https://github.com/kubernetes/cloud-provider-openstack/issues/2241),
[#2571](https://github.com/kubernetes/cloud-provider-openstack/issues/2571),
[#2624](https://github.com/kubernetes/cloud-provider-openstack/issues/2624)).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: avoid linking to issues in documentation. I found only one exception in the repo: this line references an OCCM issue because it describes a workaround for an unfixed bug rather than standard behavior. For typical use cases and resolved issues, documentation should stand alone without issue references.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 2e2348c

Comment thread pkg/openstack/loadbalancer.go Outdated
// identifier to tags. It is a no-op when uid is empty (the cluster identity
// could not be determined) or when the tag is already present, so callers
// don't need any guard logic of their own.
func withClusterIDTag(tags []string, uid string) []string {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The uid is the primary input - it's what drives the logic. Let's put it first.

Suggested change
func withClusterIDTag(tags []string, uid string) []string {
func withClusterIDTag(uid string, tags []string) []string {

And please put this function just after the withLBNameTag func.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in b7c487e

Comment thread pkg/openstack/loadbalancer.go Outdated
Comment on lines 192 to 194

@kayrus kayrus Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see my earlier comment, but I've forgotten my reasoning for changing my mind. Let's add a comment explaining why we're not using API-level tag filtering here. Primarily because we need to log warnings for unmatched tags and for transition period.

That said, I think we should still consider server-side filtering to reduce load on the Octavia API. Do you have any suggestions or concerns about this approach?

Comment thread pkg/openstack/loadbalancer.go Outdated
// and the lookup returns ErrNotFound, which causes OCCM to create a new load
// balancer instead of accidentally adopting (and overwriting) one that is
// owned by a different cluster.
func getLoadbalancerByName(ctx context.Context, client *gophercloud.ServiceClient, name string, legacyName string, clusterUID string) (*loadbalancers.LoadBalancer, error) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes more sense to convert this function to a LoadBalancer method. That would simplify calls like getLoadbalancerByName(ctx, lbaas.lb, name, legacyName, lbaas.clusterUID) to just lbaas.getLoadbalancerByName(ctx, name, legacyName). Also move this method close to other LoadBalancer methods.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in b7c487e

@kayrus

kayrus commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Just a heads-up: our current e2e test coverage is poor, and I'd like to merge #3153 before this PR. Could you write e2e tests covering the clusterID tag functionality based on #3153 and submit them as a follow-up PR? Let me know if this works for you.

Add following e2e tests:

  • loadbalancer exists, but doesn't have a kube_cluster_id_XXX tag -> OCCM reconciliation must add a missing tag
  • loadbalancer exists, but has multiple kube_cluster_id_XXX tags -> OCCM must not reconcile a loadbalancer and raise an error in events
  • prevent setting the user-define reserved tag prefixes to loadbalancer
  • and add any other tests you think are worth covering

// cross-tenant) load balancer's name to hijack ownership, shared-LB limits, or
// deletion. INVARIANT: any new tag-based ownership check must also key on
// servicePrefix, or this guarantee no longer holds.
func stripReservedTags(tags []string) []string {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a clusterIDTagPrefix prefix as an exception for reserved tags

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in b7c487e

- Move withClusterIDTag next to withLBNameTag and take the uid as the
  first argument, since the uid is the primary input.
- Convert getLoadbalancerByName into an LbaasV2 method so callers no
  longer need to pass the Octavia client and cluster UID around, and
  move it next to the other load balancer methods.
- Document why the cluster-id tag is filtered client-side rather than
  through ListOpts tag filtering: legacy load balancers without the tag
  must still be found during the transition period, and foreign-tagged
  load balancers have to be seen to log the warning.
- Treat clusterIDTagPrefix as reserved in stripReservedTags so user
  tags from the annotation cannot enter the cluster-identity namespace,
  with a test case for it.
Documentation should stand alone without references to resolved
issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[occm] Cross-cluster load balancer name collision when multiple Kubernetes clusters share an OpenStack project

4 participants