-
Notifications
You must be signed in to change notification settings - Fork 39
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
[bgp] Add new CRD to manage FRRConfiguration #322
[bgp] Add new CRD to manage FRRConfiguration #322
Conversation
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/c0370c0fe02344198cb21f1f95636f04 ❌ openstack-k8s-operators-content-provider FAILURE in 6m 41s |
This change depends on a change that failed to merge. Change openstack-k8s-operators/lib-common#588 is needed. |
c29576c
to
9f37eeb
Compare
Secondary network interfaces on pods need be announced in a BGP environment. This can be done by creating FRRConfiguration, per default in the metallb namespace. This PR introduce a new CRD which, if an instance got created, the controller watches pods * which have the NAD annotation on it * the NAD has an IPAM configured For each of them a FRRConfiguration gets created. The metallbs k8s service FRRConfiguration of that worker node is taken as the base to create this configuration. Known issue: Since there are then two FRRConfiguration, which hold same configs, like timeouts. It is not possible to update thise. The FRRConfiguration webhook will block those. A possible way to change it, would be stop the infra-operator controller-manager, delete the pod FRRConfigurations, do the change that it gets reflected in the metallb LB FRRConfiguration, then enable the controller that the pod FRRConfiguration get re-created. Depends-On: openstack-k8s-operators/lib-common#588 Jira: OSPRH-12384 Signed-off-by: Martin Schuppert <[email protected]>
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/a84b9661a7f149f981f0f0e7182d4268 ❌ openstack-k8s-operators-content-provider FAILURE in 7m 46s |
recheck |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lmiccini, stuggi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
18e54a0
into
openstack-k8s-operators:main
With [1] there is a new CRD to manage pod secondary network interface IP announcements in a BGP environment. The controller for this relies on metallb FRRConfiguraton CRD. Therefore the operator needs to be deployed. [1] openstack-k8s-operators/infra-operator#322 Signed-off-by: Martin Schuppert <[email protected]>
With [1] the infra-operator provides a CRD to manage FRRConfiguration for secondary network interfaces in a BGP environment. Therefore this CRD should be installed when the infra-operator gets deployed. This adds the metallb target to the infra_prep. [1] openstack-k8s-operators/infra-operator#322 Signed-off-by: Martin Schuppert <[email protected]>
Secondary network interfaces on pods need be announced in a BGP environment. This can be done by creating FRRConfiguration, per default in the metallb namespace.
This PR introduce a new CRD which, if an instance got created, the controller watches pods
For each of them a FRRConfiguration gets created. The metallbs k8s service FRRConfiguration of that worker node is taken as the base to create this configuration.
Known issue:
Since there are then two FRRConfiguration, which hold same configs, like timeouts. It is not possible to update thise. The FRRConfiguration webhook will block those. A possible way to change it, would be stop the infra-operator controller-manager, delete the pod FRRConfigurations, do the change that it gets reflected in the metallb LB FRRConfiguration, then enable the controller that the pod FRRConfiguration get re-created.
Depends-On: openstack-k8s-operators/lib-common#588
Depends-On: openstack-k8s-operators/lib-common#589
Jira: OSPRH-8680
Jira: OSPRH-12384