Bug 1743302: Kuryr: Expand svc net to fix VRRP ports conflicts #275
Conversation
openshift-ci-robot
added
the
size/L
|
This will fail |
dulek
force-pushed
the
octavia-vrrp-option
branch
2 times, most recently
from
ecebc66 to
fc9aca3
Compare
dulek
force-pushed
the
octavia-vrrp-option
branch
from
fc9aca3 to
65efdd9
Compare
openshift-ci-robot
added
size/XL
dulek
force-pushed
the
octavia-vrrp-option
branch
from
65efdd9 to
fb7a1d6
Compare
Octavia with the default Amphora driver uses two the IPs from the service subnet for each loadbalancer, the second being used as VRRP port. The issue with that is that OpenShift uses it's own IPAM and doesn't know about Octavia's habits leading to conflicts if IP chosen by OpenShift is already taken by one of Amphora VRRP ports. To fix this an OpenStackServiceNetwork setting is added in KuryrConfig. It will require the user to set there a CIDR of a network twice the size of ServiceNetwork and including it inside. If value is not set, the ServiceNetwork expanded to be twice the size is automatically put there. Using Neutron's allocation pools feature we limit Octavia to only use non-ServiceSubnet IP's for VRRP ports. Obviously this may lead to conflicts if expanded network overlaps with ClusterNetwork, so validation is extended to check that and other possible issues.
dulek
force-pushed
the
octavia-vrrp-option
branch
from
fb7a1d6 to
e674c87
Compare
dulek
changed the title
openshift-ci-robot
added
the
bugzilla/invalid-bug
|
@dulek: This pull request references Bugzilla bug 1743302, which is invalid:
Comment DetailsIn response to this:
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. |
|
/bugzilla refresh |
openshift-ci-robot
added
bugzilla/valid-bug
|
@dulek: This pull request references Bugzilla bug 1743302, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
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. |
|
@dulek: The following test failed, say
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. DetailsInstructions 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. |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danwinship, dulek, MaysaMacedo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
@dulek: All pull requests linked via external trackers have merged. Bugzilla bug 1743302 has been moved to the MODIFIED state. DetailsIn response to this:
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. |
5 participants
Octavia with the default Amphora driver uses two the IPs from the
service subnet for each loadbalancer, the second being used as VRRP
port. The issue with that is that OpenShift uses it's own IPAM and
doesn't know about Octavia's habits leading to conflicts if IP chosen by
OpenShift is already taken by one of Amphora VRRP ports.
To fix this the service network created in OpenStack will be expanded to
be twice bigger than the ServiceNetwork value from NetworkSpec. Then the
other half of it will be used for Amphora VRRP ports, while OpenShift
will only choose IP's from the half indicated by
NetworkSpec.ServiceNetwork.
Obviously this may lead to conflicts if expanded network overlaps with
ClusterNetwork, so validation is expanded to check that.