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 MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Controlled bare metal provisioning workflows

Available since MCC 2.30.0 (Cluster releases 21.0.0 and 20.0.0)

This section describes the controlled provisioning workflows that enable operators to have manual control over bare metal host provisioning and deployment phases. This feature allows verification of hardware inventory and configuration before proceeding with each deployment phase.

Overview

The controlled provisioning workflow comprises the following fields in the Machine specification:

  • day1Provisioning - controls the start of bare metal host provisioning

  • day1Deployment - controls the start of bare metal host deployment after provisioning

Both fields support the following values:

  • manual (default) - requires an explicit operator approval to proceed

  • auto - enables provisioning workflow that occurs either automatically from the start or manually after inspection and approval by an operator.

When using manual control, machines enter the following waiting states:

  • AwaitsProvisioning - hardware is inspected, waiting for provisioning approval

  • AwaitsDeployment - provisioning complete, waiting for deployment approval

This workflow enables operators to complete the following tasks:

  • Verify that the discovered hardware inventory matches specifications

  • Validate disk layout and network configuration after provisioning

  • Correct configuration issues before proceeding to the next phase

  • Test representative machines before scaling to all machines in a group

See also

API Reference: Machine spec:providerSpec

Deployment scenarios

The controlled provisioning workflow supports the following deployment scenarios.

Use this workflow when deploying a new management cluster where hardware verification is critical:

  1. Create all cluster-related objects (BareMetalHostInventory, BareMetalHostProfile, and Machine).

  2. Wait for bare metal hosts to switch to the available state and machines to the AwaitsProvisioning state.

  3. Review hardware inventory after inspection completes. If hardware inventory is valid, proceed to the next step. If a machine configuration is broken or invalid:

    1. Delete the affected Machine object to initiate deprovisioning.

    2. Wait for the corresponding bare metal host cleanup and deprovision to complete.

    3. Adjust the related BareMetalHostProfile object or create a new one with updated configuration.

    4. Recreate the Machine object and repeat the procedure from the step 2.

  4. Approve the BootstrapRegion object to automatically set day1Provisioning: auto for all machines.

  5. Approve deployment for all machines by setting day1Deployment: auto for all machines.

Note

Deployment starts after you add three controller nodes required for a management cluster.

Use this workflow when deploying a new MOSK cluster:

  1. Create all cluster-related objects grouped by hardware type and role.

  2. Wait for bare metal hosts to switch to the available state and machines to the AwaitsProvisioning state.

  3. Review hardware inventory. If it is valid, proceed to the next step. If a machine configuration is invalid:

    1. Delete the affected Machine object to initiate deprovisioning.

    2. Wait for the corresponding bare metal host cleanup and deprovision to complete.

    3. Adjust the related BareMetalHostProfile object or create a new one with updated configuration.

    4. Recreate the Machine object and repeat from the step 2.

  4. Approve provisioning for one representative machine per group.

  5. Validate provisioned configuration of representative machines. If it is valid, proceed to the next step. If it is invalid:

    1. Delete the affected Machine object to initiate deprovisioning.

    2. Wait for the corresponding bare metal host cleanup and deprovision to complete.

    3. Adjust the related BareMetalHostProfile object with updated provisioning configuration.

    4. Recreate the Machine object and repeat the procedure from the step 4.

  6. Scale the provisioning approval to remaining machines in each group.

  7. Approve deployment for all validated machines.

Note

Deployment starts when you add minimum 3 controller nodes and 2 worker nodes with corresponding resources for Ceph and StackLight.

Use this workflow when adding new nodes to an existing MOSK cluster with known hardware specifications:

  1. Create Machine objects for new nodes.

  2. Wait for bare metal hosts to switch to the available state and machines to the AwaitsProvisioning state.

  3. Review hardware inventory and validate it against existing BareMetalHostProfile objects. If the inventory matches the existing objects, proceed to the next step. If it is invalid:

    1. Delete the affected Machine object to initiate deprovisioning.

    2. Wait for the corresponding bare metal host cleanup and deprovision to complete.

    3. Adjust the related BareMetalHostProfile object with updated provisioning configuration or create a new one.

    4. Recreate the Machine object and repeat the procedure from the step 2.

  4. Approve provisioning for one test machine.

  5. Validate that the provisioned configuration of the test machine matches the configuration on existing cluster nodes. If it matches, proceed to the next step. If it does not match:

    1. Delete the affected Machine object to initiate deprovisioning.

    2. Wait for the corresponding bare metal host cleanup and deprovision to complete.

    3. Adjust the related BareMetalHostProfile object with updated provisioning configuration.

    4. Recreate the Machine object and repeat the procedure from the step 4.

  6. Scale provisioning and deployment approval to remaining new machines, if any.