BareMetalHostProfile

This section describes the BareMetalHostProfile resource used in Mirantis Container Cloud API to define how the storage devices and operating system are provisioned and configured.

For demonstration purposes, the Container Cloud BareMetalHostProfile custom resource (CR) is split into the following major sections:

metadata

The Container Cloud BareMetalHostProfile CR contains the following fields:

  • apiVersion

    API version of the object that is metal3.io/v1alpha1.

  • kind

    Object type that is BareMetalHostProfile.

  • metadata

    The metadata field contains the following subfields:

    • name

      Name of the bare metal host profile.

    • namespace

      Project in which the bare metal host profile was created.

Configuration example:

apiVersion: metal3.io/v1alpha1
kind: BareMetalHostProfile
metadata:
  name: default
  namespace: default

spec

The spec field of BareMetalHostProfile object contains the fields to customize your hardware configuration:

Warning

All data will be wiped during cluster deployment on devices defined directly or indirectly in the fileSystems list of BareMetalHostProfile. For example:

  • A raw device partition with a file system on it

  • A device partition in a volume group with a logical volume that has a file system on it

  • An mdadm RAID device with a file system on it

  • An LVM RAID device with a file system on it

The wipe field is always considered true for these devices. The false value is ignored.

Therefore, to prevent data loss, move the necessary data from these file systems to another server beforehand, if required.

  • devices

    List of definitions of the physical storage devices. To configure more than three storage devices per host, add additional devices to this list. Each device in the list can have one or more partitions defined by the list in the partitions field.

    • Each device in the list can have the following fields in the properties section that affect the selection of the specific device when the profile is applied to a host:

      • type (optional, string)

        The device type. Possible values: hdd, ssd, nvme. This property is used to filter selected devices by type.

      • minSizeGiB, maxSizeGiB (optional, string)

        The lower and upper limit of the selected device size. Only the devices matching these criteria are considered for allocation. Omitted parameter means no upper or lower limit.

        Since Container Cloud 2.20.0, minSize and maxSize parameters names are also available for the same purpose.

        Caution

        For MOSK-based deployments, the feature support will become available in one of the following Container Cloud releases.

        Caution

        Mirantis recommends using only one parameter name type and units throughout the configuration files. If both sizeGiB and size are used, sizeGiB is ignored during deployment and the suffix is adjusted accordingly. For example, 1.5Gi will be serialized as 1536Mi. The size without units is counted in bytes. For example, size: 120 means 120 bytes.

      • byName (optional, string)

        The specific device name to be selected during deployment, such as dev/sda.

        Warning

        With NVME devices and certain hardware disk controllers, you cannot reliably select such device by the system name. Use the workBy field to ensure reliable referencing to devices.

    • Each device in the list must have the following fields in the properties section that affect how the device will be handled:

      • wipe (mandatory, boolean)

        Defines if the device must be wiped of the data before being used.

      • workBy (optional, string)

        Defines how the device should be identified using a comma-separated string with the following values (in order of priority): by_id,by_path,by_name,by_wwn.

  • softRaidDevices Tech Preview

    List of definitions of a software-based Redundant Array of Independent Disks (RAID) created by mdadm. Use the following fields to describe an mdadm RAID device:

    • name (mandatory, string)

      Name of a RAID device. Supports the following formats:

      • dev path, for example, /dev/md0.

      • simple name, for example, raid-name that will be created as /dev/md/raid-name on the target OS.

    • devices (mandatory, list)

      List of partitions from the devices list. Expand the resulting list of devices into at least two partitions.

    • level (optional, string)

      Level of a RAID device, defaults to raid1. Possible values: raid1, raid0, raid10.

    • metadata (optional, string)

      Metadata version of RAID, defaults to 1.0. Possible values: 1.0, 1.1, 1.2. For details about the differences in metadata, see man 8 mdadm.

      Warning

      The EFI system partition partflags: ['esp'] must be a physical partition in the main partition table of the disk, not under LVM or mdadm software RAID.

  • fileSystems

    List of file systems. Each file system can be created on top of either device, partition, or logical volume. If more file systems are required for additional devices, define them in this field.

  • logicalVolumes

    List of LVM logical volumes. Every logical volume belongs to a volume group from the volumeGroups list and has the size attribute for a size in the corresponding units.

    You can also add a software-based RAID raid1 created by LVM using the following fields:

    • name

      Name of a logical volume.

    • type

      Type of a logical volume. If you require a usual logical volume, you can omit this field.

      Possible values:

      • linear

        Default. A usual logical volume. This value is implied for bare metal host profiles created using the Container Cloud release earlier than 2.12.0 where the type field is unavailable.

      • raid1 Tech Preview

        Serves to build the raid1 type of LVM. Equals to the lvcreate --type raid1... command. For details, see man 8 lvcreate and man 7 lvmraid.

    • vg

      Name of a volume group. Must be a name from the volumeGroups list.

    • sizeGiB (or size Available since 2.20.0)

      Size of a logical volume in gigabytes. When set to 0, all available space on the corresponding volume group will be used. The 0 value equals -l 100%FREE in the lvcreate command.

      Note

      The size option will be available for MOSK-based deployments in one of the following Container Cloud releases.

      Caution

      Mirantis recommends using only one parameter name type and units throughout the configuration files. If both sizeGiB and size are used, sizeGiB is ignored during deployment and the suffix is adjusted accordingly. For example, 1.5Gi will be serialized as 1536Mi. The size without units is counted in bytes. For example, size: 120 means 120 bytes.

  • volumeGroups

    List of definitions of LVM volume groups. Each volume group contains one or more devices or partitions from the devices list.

  • preDeployScript

    Shell script that executes on a host before provisioning the target operating system inside the ramfs system.

  • postDeployScript

    Shell script that executes on a host after deploying the operating system inside the ramfs system that is chrooted to the target operating system. To use a specific default gateway (for example, to have Internet access) on this stage, refer to Override the default dnsmasq settings.

  • grubConfig

    List of options passed to the Linux GRUB bootloader. Each string in the list defines one parameter.

  • kernelParameters:sysctl

    List of kernel sysctl options passed to /etc/sysctl.d/999-baremetal.conf during a bmh provisioning.

  • kernelParameters:modules

    List of kernel modules options passed to /etc/modprobe.d/{filename} during a bmh provisioning.

Configuration example:

spec:
  devices:
  - device:
      wipe: true
    partitions:
    - dev: ""
      name: bios_grub
      partflags:
      - bios_grub
      size: 4Mi
      ...
  - device:
      wipe: true
    partitions:
    - dev: ""
      name: lvm_lvp_part
  softRaidDevices:
    - name: root
      level: raid1  ## <-- MD raid1
      devices:
        - partition: root_part1
        - partition: root_part2
    - name: raid-name
      level: raid0  ## <-- MD raid0
      devices:
        - partition: rest_sda
        - partition: rest_sdb
  logicalVolumes:
    - name: root
      type: raid1  ## <-- LVM raid1
      vg: vg-root
      size: 39.9Gi
    - name: data
      type: linear
      vg: vg-data
      size: 0
  fileSystems:
  - fileSystem: vfat
    partition: config-2
  - fileSystem: vfat
    mountPoint: /boot/efi
    partition: uefi
    ...
  - fileSystem: ext4
    logicalVolume: lvp
    mountPoint: /mnt/local-volumes/
  logicalVolumes:
  - name: root
    size: 0
    vg: lvm_root
  - name: lvp
    size: 0
    vg: lvm_lvp
  postDeployScript: |
    #!/bin/bash -ex

    echo $(date) 'post_deploy_script done' >> /root/post_deploy_done
  preDeployScript: |
    #!/bin/bash -ex

    echo 'ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"' > /etc/udev/rules.d/60-ssd-scheduler.rules
    echo $(date) 'pre_deploy_script done' >> /root/pre_deploy_done
  volumeGroups:
  - devices:
    - partition: lvm_root_part
    name: lvm_root
  - devices:
    - partition: lvm_lvp_part
    name: lvm_lvp
  grubConfig:
    defaultGrubOptions:
    - GRUB_DISABLE_RECOVERY="true"
    - GRUB_PRELOAD_MODULES=lvm
    - GRUB_TIMEOUT=20
  kernelParameters:
    sysctl:
      kernel.panic: "900"
      kernel.dmesg_restrict: "1"
      kernel.core_uses_pid: "1"
      fs.file-max: "9223372036854775807"
      fs.aio-max-nr: "1048576"
      fs.inotify.max_user_instances: "4096"
      vm.max_map_count: "262144"
    modules:
      - filename: kvm_intel.conf
        content: |
          options kvm_intel nested=1