Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Obtain and use details about network interfaces

To simplify operations with L2 templates, before you start creating them, inspect the general workflow of a network interface name gathering and processing.

Network interface naming workflow:

1. The operator creates a BareMetalHostInventory object.

   Note

   Before update of the management cluster to 2.29.0 (Cluster release 16.4.0), instead of BareMetalHostInventory, use the BareMetalHost object. For details, see BareMetalHost resource.

   Caution

   While the Cluster release of the management cluster is 16.4.0, BareMetalHostInventory operations are allowed to m:kaas@management-admin only. This limitation is lifted once the management cluster is updated to the Cluster release 16.4.1 or later.

2. The BareMetalHostInventory object executes the introspection stage and becomes ready.

3. The operator collects information about NIC count, naming, and so on for further changes in the mapping logic.

   At this stage, the NICs order in the object may randomly change during each introspection, but the NICs names are always the same. For more details, see Predictable Network Interface Names.

   For example:

   # Example commands:
   # kubectl -n mosk-ns get bmh baremetalhost1 -o custom-columns='NAME:.metadata.name,STATUS:.status.provisioning.state'
   # NAME            STATE
   # baremetalhost1  ready
   
   # kubectl -n mosk-ns get bmh baremetalhost1 -o yaml
   # Example output:
   
   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   ...
   status:
   ...
       nics:
       - ip: fe80::ec4:7aff:fe6a:fb1f%eno2
         mac: 0c:c4:7a:6a:fb:1f
         model: 0x8086 0x1521
         name: eno2
         pxe: false
       - ip: fe80::ec4:7aff:fe1e:a2fc%ens1f0
         mac: 0c:c4:7a:1e:a2:fc
         model: 0x8086 0x10fb
         name: ens1f0
         pxe: false
       - ip: fe80::ec4:7aff:fe1e:a2fd%ens1f1
         mac: 0c:c4:7a:1e:a2:fd
         model: 0x8086 0x10fb
         name: ens1f1
         pxe: false
       - ip: 192.168.1.151 # Temp. PXE network adress
         mac: 0c:c4:7a:6a:fb:1e
         model: 0x8086 0x1521
         name: eno1
         pxe: true
    ...
   

4. The operator selects from the following options:

   • Create an L2Template object with the ifMapping configuration. For details, see Create L2 templates.

   • Create a Machine object, with the l2TemplateIfMappingOverride configuration. For details, see Override network interfaces naming and order.

5. The operator creates a Machine or Subnet object.

6. The baremetal-provider service links the Machine object to the BareMetalHostInventory object.

7. The kaas-ipam and baremetal-provider services collect hardware information from the BareMetalHostInventory object and use it to configure host networking and services.

8. The kaas-ipam service:

   1. Spawns the IpamHost object.

   2. Renders the L2Template object.

   3. Spawns the ipaddr object.

   4. Updates the IpamHost object status with all rendered and linked information.

9. The baremetal-provider service collects the rendered networking information from the IpamHost object

10. The baremetal-provider service proceeds with the IpamHost object provisioning.

Now proceed to Create subnets.