-
Task
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
None
-
BU Product Work
-
3
-
False
-
None
-
False
-
OCPSTRAT-1430 - Hosted Control Plane for OpenStack clusters-DevPreview
-
-
-
ShiftStack Sprint 258, ShiftStack Sprint 261, ShiftStack Sprint 262
Being able to connect the node pools to additional networks, like we support already on standalone clusters.
This task will be necessary for some use cases, like using Manila CSI on a storage network, or running NFV workload on a SRIOV provider network or also running ipv6 dual stack workloads on a provider network.
I see at least 2 options:
- We patch CAPO to support AdditionalNetworks (type: []NetworkParam), and we append what is in the spec.ports when creating the OpenStackMachine with the additional networks
- We provision CAPO cluster with ManagedSubnets and provide ports to the OpenStackMachine.Spec.Ports directly. No need to patch CAPO.
Either way, I start to think that we could simply HCP/OSP:
in BYON, the user will have to provide Router, Network and Subnets in OpenStackCluster.Spec.
In non-BYON (the current default and supported way), we would ALWAYS provide ManagedSubnets (we'll have a default []SubnetSpec) so whether we have additional networks, we can have control over OpenStackMachine.Spec.Ports .
One thing we need to solve as well is the fact that when a Node has > 1 port, kubelet won't necessarily listen on the primary interface. We need to address that too; and it seems CPO has an option to define the primary network name: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/openstack-cloud-controller-manager/using-openstack-cloud-controller-manager.md#networking
If we don't solve that, the nodepool (worker) won't join the cluster since Kubelet might listen on the wrong interface.
- is depended on by
-
OSASINFRA-3566 NFV ready node pools
- Closed
- links to