Use provided VipPortID for OpenStack LB #44387
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-github-robot
added
size/M
|
Hi @jamiehannaford. 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 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/test-infra repository. I understand the commands that are listed here. |
|
This change is |
jamiehannaford
force-pushed
the
fix-port-allocation
branch
from
8f226ef to
622c69c
Compare
|
ok to test |
|
/approve |
k8s-github-robot
added
the
approved
|
@jdef @mikedanese Thanks for reviewing. Does this need anything else before LGTM? |
|
Would somebody mind tagging this with /lgtm? |
idvoretskyi
added
the
area/provider/openstack
|
cc @anguslees @kubernetes/sig-openstack-pr-reviews |
| return nil, fmt.Errorf("Error getting port for LB vip %s: %v", loadbalancer.VipAddress, err) | ||
| } | ||
| floatIP, err := getFloatingIPByPortID(lbaas.network, port.ID) | ||
| portID := loadbalancer.VipPortID |
There was a problem hiding this comment.
I remember why I hate working on this code :(
gophercloud/gophercloud#20 suggests that VipPortID will be undefined when loadbalancer is the result of the "create" branch way above. Can we confirm that this actually works in the "LB doesn't already exist" case on a few recent openstack releases - or perhaps change the create case way above to do a regular "get" after the "create"?
There was a problem hiding this comment.
It's included in an integration test so I'm pretty sure vip_port_id is returned in the create response. We've also been running this in a dev env for over a week, and things are fixed.
@coreypobrien are we doing create ops?
There was a problem hiding this comment.
The change looks good otherwise, so I'm happy to let this go ahead and let it get more widespread testing. This section of code has been unusually full of dragons, and most of it not caused by us.
/lgtm
There was a problem hiding this comment.
Thanks. Would you mind commenting on the main PR thread, I don't think the merge bot tracks /lgtm in inline comments :)
|
Yo bots! I said: |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: anguslees, jamiehannaford, mikedanese
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
@k8s-bot cvm gce e2e test this |
|
Automatic merge from submit-queue |
|
@jamiehannaford: The following test(s) failed:
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/test-infra repository. I understand the commands that are listed here. |
…cation Automatic merge from submit-queue Use provided VipPortID for OpenStack LB **What this PR does / why we need it**: When creating an OpenStack LoadBalancer, Kubernetes will search through the tenant trying to match the LB's VIP with a port. This is problematic because multiple ports may have the same fixed IP, therefore leading to routing inconsistencies. We should use the port ID provided by the LB's response body instead. **Which issue this PR fixes**: kubernetes#43909 **Special notes for your reviewer**: Since this involves non-deterministic testing, it'd be best if we can run this in a staging environment for a few days before merging (say until early next week). **Release note**: ```release-note Fixes issue during LB creation where ports where incorrectly assigned to a floating IP ```
What this PR does / why we need it:
When creating an OpenStack LoadBalancer, Kubernetes will search through the tenant trying to match the LB's VIP with a port. This is problematic because multiple ports may have the same fixed IP, therefore leading to routing inconsistencies. We should use the port ID provided by the LB's response body instead.
Which issue this PR fixes:
#43909
Special notes for your reviewer:
Since this involves non-deterministic testing, it'd be best if we can run this in a staging environment for a few days before merging (say until early next week).
Release note: