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

Now, 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.

Add a bare metal host using CLI¶

This section describes how to add bare metal hosts using the MOSK management CLI during a MOSK cluster creation.

To add a bare metal host:

Create a project for MOSK clusters.
Configure BIOS on a bare metal host.
Log in to the host where your management cluster kubeconfig is located and where kubectl is installed.
Create a YAML file that describes the unique credentials of the new bare metal host as a BareMetalHostCredential object.
```
apiVersion: kaas.mirantis.com/v1alpha1
kind: BareMetalHostCredential
metadata:
  labels:
    kaas.mirantis.com/provider: baremetal
  name: <bare-metal-host-credential-unique-name>
  namespace: <mosk-cluster-project-name>
spec:
  username: <ipmi-user-name>
  password:
    value: <ipmi-user-password>
```
- In the metadata section, add a unique credentials name and the name of the non-default project (namespace) dedicated for the MOSK cluster being created.
- In the spec section, add the IPMI user name and password in plain text to access the Baseboard Management Controller (BMC). The password will not be stored in the BareMetalHostCredential object but will be erased and saved in an underlying Secret object.
Caution

Each bare metal host must have a unique BareMetalHostCredential. For details about the BareMetalHostCredential object, refer to BareMetalHostCredential resource.
Apply this secret YAML file to your deployment:

Warning

The kubectl apply command automatically saves the applied data as plain text into the kubectl.kubernetes.io/last-applied-configuration annotation of the corresponding object. This may result in revealing sensitive data in this annotation when creating or modifying the object.

Therefore, do not use kubectl apply on this object. Use kubectl create, kubectl patch, or kubectl edit instead.

If you used kubectl apply on this object, you can remove the kubectl.kubernetes.io/last-applied-configuration annotation from the object using kubectl edit.
```
kubectl create -n <moskClusterProjectName> -f ${<bmh-cred-file-name>}.yaml
```

Create a YAML file that contains a description of the new bare metal host. For example:

apiVersion: kaas.mirantis.com/v1alpha1
kind: BareMetalHostInventory
metadata:
  annotations:
    inspect.metal3.io/hardwaredetails-storage-sort-term: hctl ASC, wwn ASC, by_id ASC, name ASC
  labels:
    kaas.mirantis.com/baremetalhost-id: <unique-bare-metal-host-hardware-node-id>
    kaas.mirantis.com/provider: baremetal
  name: <bare-metal-host-unique-name>
  namespace: <mosk-cluster-project-name>
spec:
  bmc:
    address: <ip-address-for-bmc-access>
    bmhCredentialsName: <bare-metal-host-credential-unique-name>
  bootMACAddress: <bare-metal-host-boot-mac-address>
  online: true

Note

If you have a limited amount of free and unused IP addresses for server provisioning, you can add the baremetalhost.metal3.io/detached annotation that pauses automatic host management to manually allocate an IP address for the host. For details, see Manually allocate IP addresses for bare metal hosts.

For a detailed fields description, see API Reference: BareMetalHostInventory resource.

Apply this YAML file to your deployment:
```
kubectl create -n <moskClusterProjectName> -f ${<bare-metal-host-config-file-name>}.yaml
```
During provisioning, baremetal-operator inspects the bare metal host and moves it to the Preparing state. The host becomes ready to be linked to a bare metal machine.

Caution

If changing or adding of DHCP subnets is required to bootstrap new nodes, wait after changing or adding of DHCP subnets until the dnsmasq pod becomes ready, then create bare metal host objects as described above.

For details about the related issue, refer to Inspection error on bare metal hosts after dnsmasq restart.

Verify the new bare metal host object status:

kubectl -n <mosk-cluster-project-name> get bmh -o wide <bare-metal-host-unique-name>

Example of system response:

NAMESPACE    NAME   STATUS   STATE      CONSUMER  BMC                        BOOTMODE  ONLINE  ERROR  REGION
my-project   bmh1   OK       preparing            ip-address-for-bmc-access  legacy    true           region-one

During provisioning, the status changes as follows:

registering
inspecting
preparing

After the bare metal host object switches to the preparing stage, the inspecting phase finishes and you can verify that hardware information is available in the object status and matches the MOSK cluster hardware requirements. For example:

Verify the status of hardware NICs:

kubectl -n <mosk-cluster-project-name> get bmh <bare-metal-host-unique-name> -o json |  jq -r '[.status.hardware.nics]'

Example of system response:

[
  [
    {
      "ip": "172.18.171.32",
      "mac": "ac:1f:6b:02:81:1a",
      "model": "0x8086 0x1521",
      "name": "eno1",
      "pxe": true
    },
    {
      "ip": "fe80::225:90ff:fe33:d5ac%ens1f0",
      "mac": "00:25:90:33:d5:ac",
      "model": "0x8086 0x10fb",
      "name": "ens1f0"
    },
 ...

Verify the status of RAM:

kubectl -n <mosk-cluster-project-name> get bmh <bare-metal-host-unique-name> -o json |  jq -r '[.status.hardware.ramMebibytes]'

Example of system response:

[
  98304
]

Now, proceed with Create a custom bare metal host profile.