Skip to content

cloudprovider: Remove GetLoadBalancerName from LoadBalancer interface #133423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

justinsb
Copy link
Member

@justinsb justinsb commented Aug 7, 2025

The GetLoadBalancerName method is obsolete and no longer used by the cloud provider. This commit removes the method from the LoadBalancer interface and tests.

The method is problematic, because it surfaces a cloud-specific concept without clear direction as to how it is used. Cloud providers may have multiple identifiers for a single load balancer.

/kind cleanup

NONE

The GetLoadBalancerName method is obsolete and no longer used by the
cloud provider. This commit removes the method from the LoadBalancer
interface and tests.

The method is problematic, because it surfaces a cloud-specific
concept without clear direction as to how it is used.  Cloud providers
may have multiple identifiers for a single load balancer.
@k8s-ci-robot k8s-ci-robot added the release-note-none Denotes a PR that doesn't merit a release note. label Aug 7, 2025
@k8s-ci-robot
Copy link
Contributor

Please note that we're already in Test Freeze for the release-1.34 branch. This means every merged PR will be automatically fast-forwarded via the periodic ci-fast-forward job to the release branch of the upcoming v1.34.0 release.

Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Thu Aug 7 08:56:53 UTC 2025.

@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Aug 7, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

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 sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. sig/network Categorizes an issue or PR as relevant to SIG Network. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Aug 7, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject 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.

@k8s-ci-robot k8s-ci-robot added needs-priority Indicates a PR lacks a `priority/foo` label and requires one. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Aug 7, 2025
@k8s-ci-robot
Copy link
Contributor

@justinsb: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-kubernetes-cmd 63c5b78 link true /test pull-kubernetes-cmd
pull-kubernetes-e2e-kind 63c5b78 link true /test pull-kubernetes-e2e-kind
pull-kubernetes-conformance-kind-ga-only-parallel 63c5b78 link true /test pull-kubernetes-conformance-kind-ga-only-parallel
pull-kubernetes-e2e-gce 63c5b78 link true /test pull-kubernetes-e2e-gce
pull-kubernetes-verify 63c5b78 link true /test pull-kubernetes-verify

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

Copy link
Contributor

@elmiko elmiko left a comment

Choose a reason for hiding this comment

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

i think this looks ok, do we have any idea about the coverage of SIG owned providers that are using the GetLoadBalancerName interface?

@justinsb
Copy link
Member Author

justinsb commented Aug 7, 2025

i think this looks ok, do we have any idea about the coverage of SIG owned providers that are using the GetLoadBalancerName interface?

I can try to take a look, but I want to point out that we specifically need to worry about providers that use GetLoadBalancerName through our LoadBalancer Interface (I believe). In other words, nothing should stop (say) AWS from implementing GetLoadBalancerName on their load balancer implementation, it just isn't part of the standard LoadBalancer interface. So we're looking for generic controller implementations that use LoadBalancer and GetLoadBalancerName - and I think the canonical one is in this repo.

Of course if I'm wrong about this then I don't think we want this PR!

The reason for this PR, BTW, is that on GCP we have many objects, and if we are to implement multiple protocols then we need two ForwardingRules, and thus there will definitely be two names. It's not the end of the world to keep this method (we still have a "base name" which we will use for singleton objects), but I realized that we aren't actually using this method here so it's just a cause for (my) confusion.

@elmiko
Copy link
Contributor

elmiko commented Aug 11, 2025

In other words, nothing should stop (say) AWS from implementing GetLoadBalancerName on their load balancer implementation, it just isn't part of the standard LoadBalancer interface. So we're looking for generic controller implementations that use LoadBalancer and GetLoadBalancerName - and I think the canonical one is in this repo.

that makes good sense to me. my concern, albeit perhaps unfounded, is that there is some cloud provider using the default implementation. i /think/ the changes here shouldn't affect that, but i was just curious.

The reason for this PR, BTW, is that on GCP we have many objects, and if we are to implement multiple protocols then we need two ForwardingRules, and thus there will definitely be two names. It's not the end of the world to keep this method (we still have a "base name" which we will use for singleton objects), but I realized that we aren't actually using this method here so it's just a cause for (my) confusion.

makes sense, and i tend to agree about the rationale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cloudprovider cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note-none Denotes a PR that doesn't merit a release note. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. sig/network Categorizes an issue or PR as relevant to SIG Network. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants