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.
Format and structure of a module package¶
Available since MCC 2.26.0 (17.1.0 and 16.1.0) TechPreview
A module package for host operating system configuration management is an archive that contains Ansible playbooks, metadata, and optionally a JSON-validation schema.
Requirements¶
Archive the file with the module package in the GZIP format.
Implement all playbooks for Ansible version used by a specific Cluster release of your cluster. For example, in Cluster releases 16.2.0 and 17.2.0, Ansible collection 5.10.0 and Ansible core 2.12.10 are used.
To verify the Ansible version in a specific Cluster release, refer to the Release artifacts > Management cluster artifacts > System and MCR artifacts section of the required release. For example, ClusterRelease artifacts.
Note
Mirantis recommends implementing each module in modular approach avoiding a single module for everything. This ensures maintainability and readability, as well as improves testing and debugging. For details, refer to Global recommendations for implementation of custom modules.
Archive format¶
The common structure within a module archive is as follows:
main.yamlFile name of the primary playbook that defines tasks to be executed.
metadata.yamlMetadata of the module such as name, version, and relevant documentation URLs.
schema.jsonOptional. JSON schema for validating module-specific configurations that are restricted values.
Metadata file format¶
The common structure of metadata.yaml is as follows:
nameRequired. Name of the module.
versionRequired. Version of the module.
docURLOptional. URL to the module documentation.
descriptionOptional. Brief summary of the module, useful if the complete documentation is too detailed.
playbookRequired. Path to the module playbook. Path must be related to the archive root that is
directory/playbook.yamlifdirectoryis a directory in the root of the archive.
valuesJsonSchemaOptional. Path to the JSON-validation schema of the module. Path must be related to the archive root that is
directory/schema.jsonifdirectoryis a directory in the root of the archive.
deprecatesOptional. Available since Container Cloud 2.28.0 (Cluster releases 17.3.0 and 16.3.0). List of modules that are deprecated by the module. For details, see Module deprecation.
supportedDistributionsOptional. Available since Container Cloud 2.28.0 (Cluster releases 17.3.0 and 16.3.0). List of operating system distributions that are supported by the current module. An empty list means support of any distribution by the current module.
Example of metadata.yaml:
name: module-sample
version: 1.0.0
docURL: https://docs.mirantis.com
description: 'Module for sample purposes'
playbook: main.yaml
valuesJsonSchema: schema.json
deprecates:
- name: another-module-to-deprecate
version: 0.1.0
JSON-validation schema format¶
For description of JSON schema and its format, refer to JSON Schema official documentation.
Example of schema.json:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"kernel.panic": {"type": "string", "const": "1"}
}
}
Playbook format¶
A playbook for a module must follow the rules of a particular Ansible
version as mentioned in Requirements.
The only specific requirement for playbook format is to use the values
variable that consists of values described in the
inventory file.
Note
As hosts are selected in a HostOSConfiguration object, Mirantis
recommends using hosts: all in module playbooks.
For example:
- name: <variable-name>
hosts: all
become: true
tasks:
- name: <value-name>
module:
name: "{{ item.key }}"
value: "{{ item.value }}"
state: present
reload: yes
with_dict: "{{ values }}"
Inventory format¶
An archive of a module does not require an inventory because the inventory
is generated by lcm-controller while processing configurations.
The format of the generated inventory is as follows:
all:
hosts:
localhost:
ansible_connection: local
vars:
values:
{{- range $key, $value := .Values }}
{{ $key }}: {{ $value }}
{{- end }}
The .Values parameter contains the values from the provided module
configuration of the HostOSConfiguration object. For details, see
HostOSConfiguration.