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 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 custom module to a MOSK deployment

TechPreview since MCC 2.26.0 (17.1.0 and 16.1.0)

Important

The cloud operator takes all risks and responsibility for module execution on cluster machines. For any questions, contact Mirantis support.

You can create a new hocm object or add a new entry with a custom-made module to the .spec.modules list in the existing hocm object. For the object specification, see HostOSConfigurationModules.

Warning

Do not modify the mcc-modules object that contains only Mirantis-provided modules. Any changes to this object will be overwritten with data from an external source.

To add a custom module to a MOSK deployment:

  1. If you use a proxy on the management and/or MOSK cluster, ensure that the custom module can be downloaded through that proxy, or domain address of the module URL is added to the NO_PROXY value of the related Proxy objects.

    This way, the HostOSConfiguration Controller can download and verify the module and its input parameters on the management cluster. After that, the LCM Agent can download the module to any cluster machines for execution.

    Caution

    A management and MOSK cluster can use different Proxy objects. In this case, both proxies must satisfy the requirement above. For the Proxy object details, see Proxy support and cache of artifacts.

  2. In the hocm object, set the name and version fields with the same values from the corresponding fields in metadata.yaml of the module archive. For details, see Metadata file format.

  3. Set the url field with the URL to the archive file of the module. For details, see Format and structure of a module package.

  4. Set the sha256sum field with the calculated SHA256 hash sum of the archive file.

    To obtain the SHA256 hash sum, you can use the following example command:

    curl -sSL https://fully.qualified.domain.name/to/module/archive/name-1.0.0.tgz | shasum -a 256 | tr -d ' -'
bc5fafd15666cb73379d2e63571a0de96fff96ac28e5bce603498cc1f34de299

After applying the changes, monitor the hocm object status to ensure that the new module has been successfully validated and is ready to use. For the hocm status description, see HostOSConfigurationModules status.

Fetching and validating a module archive

After you add a custom module to a MOSK deployment, the process of fetching a module archive involves the following automatic steps:

  1. Retrieve the .tgz archive of the module and unpack it into a temporary directory.

  2. Retrieve the metadata.yaml file and validate its contents. Once done, the status of the module in the hocm object reflects whether the archive fetching and validating succeeded or failed.

The validation process includes the following verifications:

  1. Validate that the SHA256 hash sum of the archive equals the value defined in the sha256sum field.

  2. Validate that the playbook key is present.

  3. Validate that the file defined in the playbook key value exists in the archive and has a non-zero length.

  4. Validate that the name and version values from metadata.yaml equal the corresponding fields in the hocm object.

  5. If the valuesJsonSchema key is defined, validate that the file from the key value exists in the archive and has a non-zero length.