documentation.suse.com / SUSE Edge Documentation / Tips and Tricks / Metal3

31 Metal3

 

31.1 Ironic

 

31.1.1 Predictable network names

 

Due to a known issue, if you are trying to configure predictable names for the target OS network devices and you end up in errors, seeing that the discovered device names have different naming pattern, then you have a couple of options:

Option 1: Use two network configuration secrets, one for the inspection/provisioning phase and another for the deployed OS.

It is recommended to create two different secrets with the network configuration, one to be used with the IPA using the device names as IPA will discover and use it as preprovisioningNetworkDataName on the BareMetalHost definition and another secret with the device names as SL Micro will discover and use it as networkData.name on the BareMetalHost definition:

Example of creating two secrets, one to be used by IPA and another to be used by the target operating system

  • Target OS (SL Micro) secret:

apiVersion: v1
kind: Secret                                                                                                                                                               metadata:
  name: controlplane-0-networkdata-os
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: enp1s0
      type: ethernet
      state: up
      mac-address: "00:f3:65:8a:a3:b0"
      ipv4:
        address:
        - ip:  192.168.125.200
          prefix-length: 24
        enabled: true
        dhcp: false                                                                                                                                     dns-resolver:
      config:
        server:
        - 192.168.125.1
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.125.1
        next-hop-interface: enp1s0

  • ironic (IPA) secret:

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata-ipa
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: enp1s0np0
      type: ethernet
      state: up
      mac-address: "00:f3:65:8a:a3:b0"
      ipv4:
        address:
        - ip:  192.168.125.200
          prefix-length: 24
        enabled: true
        dhcp: false
    dns-resolver:
      config:
        server:
        - 192.168.125.1
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.125.1
        next-hop-interface: enp1s0np0

  • Apply on bare metal host:

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  preprovisioningNetworkDataName: controlplane-0-networkdata-ipa
  networkData:
    name: controlplane-0-networkdata-os
...

Option 2: Alternateively, you can use UUIDs as identifiers.

How to get the UUIDs you need:

  1. In your OpenSUSE or SLES machine install nmc: zypper in nm-configurator

  2. then run directly: nmc generate --config-dir /path/to/your/config --output-dir /where/you/want/it now in the output files you should have the UUIDs that you can use in your configuration.

  3. Alternatively, if you don’t use OpenSUSE or SLES, you can use the nmc through the Edge Image Builder container image: podman run -it --rm -v $(pwd):/path/to/your/config:Z --entrypoint=/usr/bin/nmc registry.suse.com/edge/3.3/edge-image-builder:1.2.1 generate --confi g-dir /path/to/your/config --output-dir /where/you/want/it

31.2 BareMetalHost selection and Cluster association

 

Once a Metalˆ3ˆ cluster object and its corresponding associated objects are created, a process to choose which BareMetalHost will be part of the cluster is performed. This process connects a BareMetalHost with a specific Metal3MachineTemplate using standard Kubernetes labels and selectors.

As an example, each BareMetalHost is labeled to identify its properties and intended cluster (e.g., its cluster-role, the cluster name, location, etc.):

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: mynode1
  labels:
    cluster-role: control-plane
    cluster: foobar
    location: madrid
    datacenter: xyz
<snip>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: mynode2
  labels:
    cluster-role: worker
    cluster: foobar
    location: madrid
    datacenter: xyz
<snip>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: mynode3
  labels:
    cluster-role: worker
    cluster: foobar2
    location: madrid
    datacenter: xyz
<snip>
...

Then, the Metal3MachineTemplate object uses the spec.hostSelector field to match the desired BareMetalHost.

Both matchLabels (for exact key-value matching) and matchExpressions (for more complex rules) can be used:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: foobar-cluster-controlplane
  namespace: mynamespace
spec:
  template:
    spec:
      hostSelector:
        matchLabels:
          cluster-role: control-plane
          cluster: foobar
<snip>
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: foobar-cluster-worker
  namespace: mynamespace
spec:
  template:
    spec:
      hostSelector:
        matchExpressions:
          - { key: cluster-role, operator: In, values: [worker] }
          - { key: cluster, operator: In, values: [foobar] }
<snip>
Note
Note

Kubernetes namespaces can be also used to better organize the different objects.