-
Bug
-
Resolution: Unresolved
-
Normal
-
rhos-18.0.0
-
None
-
False
-
-
False
-
?
-
?
-
?
-
?
-
None
-
-
-
Moderate
When creating the network topology for RHOSO, it's possible the physical interface names are inconsistent on the nodes. The current documentation assumes that all interface names are consistent. When they are inconsistent, the current documentation does not allow for deployment of the RHOSO networking due to how network manifests reference the control plane interface name directly.
There are two requests here:
- add a note indicating that the interface names for the ctlplane interface must be consistent across all nodes
- when interface names are not consistent across the nodes, then either a Linux Bridge (unsupported) or a Linux Bond needs to be created in order to provide an alternative name for the interface that can be referenced by other objects, hiding the inconsistent interface names from the other network manifests
Here is an example NNCP that instead uses a single interface within a Linux Bond in order to provide a vanity name for use by Network Attachment Definitions etc.
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: osp-ens7-shift1-master-2 spec: desiredState: interfaces: [...] - description: ctlplane bond interface ipv4: address: - ip: 192.168.122.3 prefix-length: 24 dhcp: false enabled: true ipv6: enabled: false link-aggregation: mode: active-backup options: miimon: "140" port: - ens8 mtu: 1500 name: ctlplane state: up type: bond
And the corresponding net-attach-def that uses the vanity name ctlplane rather than ens8 (the other nodes are ens7).
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: ctlplane namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "ctlplane", "type": "macvlan", "master": "ctlplane", "ipam": { "type": "whereabouts", "range": "192.168.122.0/24", "range_start": "192.168.122.30", "range_end": "192.168.122.70" } }