-
Notifications
You must be signed in to change notification settings - Fork 596
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
[occm] loadbalancer doesn't honor the spec.loadBalancerIP
on service update
#2443
Comments
@kayrus spec.LoadbalancerIP is deprecated, see kubernetes/cloud-provider-gcp#371 kubernetes/kubernetes#107235 So I think the annotation for openstack could be something like all of these https://github.com/search?q=repo%3Akubernetes%2Fcloud-provider-openstack%20loadbalancerip&type=code should be removed and migrated to new way of doing things |
Yes, I agree with @zetaab, if possible, we can adopt the new way of assigning the floating IP for LB. nevertheless, one thing I would like to clarify is that "Field Service.Spec.LoadBalancerIP is deprecated, and it will not be deleted". I have verified the feature of updating the Octavia LB with a single floating IP, as described in the documentation. and the result is FIP of this LB has been changed. I would like to propose fixing this issue to ensure consistency with the documentation. I've noticed that the logic currently only allows newly created LBs to use the LoadBalancerIP. Perhaps we could consider a hot-fix similar to the method described below. if (floatIP == nil && loadBalancerIP != "") || (floatIP != nil && floatIP. FloatingIP != loadBalancerIP) {
// check & attach the FloatingIP to LB
} |
From my perspective it would be best to switch to the annotation first. It doesn't hurt to use the existing field, but note that very soon we'll be adding dual stack LBs support. There I'll advocate to ignore |
I believe the annotation approach mirrors the existing method(the same logic). For this issue, I intend to address it ASSP. |
seems PR #2451 is intend to fix with older way while we actually want to use loadbalancer.openstack.org/floating-ip |
@jichenjc, I've incorporated the annotation approach and adjusted the priority for compatibility purposes. |
I notice this PR #2451 introduce a new annotation |
@jeffyjf well if you look these annotations cloud-provider-openstack/pkg/openstack/loadbalancer.go Lines 69 to 103 in eeba485
|
@zetaab I agree with you, I also think there are not many service.beta.kubernetes.io annotations. I just think the annotation |
it does not mean always that. When you create new loadbalancer and want to provision new floating ip, you do not need to define |
Yep, what Jesse says. All LBs are external in CPO by default. We cannot change that. We could probably make setting |
The annotation proposal from @kayrus has been revised. as follows:
from my perspective, if the intention is to utilize annotation for dual-stack support, maintaining a single, clear annotation should be considered for simplicity and to avoid confusion. |
and how would that work if I have dualstack setup and I specify also loadbalancer.openstack.org/floatingip-v4? Which annotation it should use? |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale Still valid to me. |
Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
Documentation says:
However once I create a svc with no
spec.loadBalancerIP
defined, OCCM assigns the random FIP to a LB. If I want to change the FIP on the existing service by setting thespec.loadBalancerIP
, the setting persists, but the actual FIP is not assigned.What you expected to happen:
I expect OCCM to assign a new FIP once
spec.loadBalancerIP
is changed.How to reproduce it:
spec.loadBalancerIP
to a desired valueAnything else we need to know?:
cloud-provider-openstack/pkg/openstack/loadbalancer.go
Lines 1039 to 1041 in ed517e1
see also #2377, where this bug is seen more clearly.
Environment:
The text was updated successfully, but these errors were encountered: