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

32 Metal3

 

32.1 Ironic

 

32.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

32.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.

32.3 Clean up old EFI boot entries

 

Sometimes, the UEFI boot manager contains multiple entries for older operating systems that are probably not needed anymore (especially for host being re-provisioned multiple times). You can clean up those old entries by following any of the following procedures:

  • Delete them on the BIOS/EFI setup interface directly (the exact procedure will depend on the hardware).

  • Run the UEFI bcfg shell as:

    # List the entries
bcfg boot dump -b
# Delete entry number X
bcfg boot rm X
# X is the number associated the entry to remove. For example, if the entry is "Boot0002 foobar", then X is 2.

  • Use efibootmgr on a Linux system as:

    # List the entries
efibootmgr -v
# Delete entry number X
efibootmgr -b X -B

The process may leave orphaned files on the EFI System Parition (ESP), usually found under subdirectories named by the vendor (e.g., EFI/opensuse or EFI/Microsoft). While these files are generally harmless, they should be deleted if they consume excessive space as it can prevent the installation of a new OS or a boot manager update. Removal may require explicitly mounting the ESP, typically mounted as /boot/efi/EFI on Linux systems.