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.

OpenStackDeployment spec:services

The spec:services section of the OpenStackDeployment custom resource defines lowest-level values for Helm charts deployed by the OpenStack Controller (Rockoon), bypassing its high-level logic and guardrails.

Rockoon does not validate the spec:services content. The controller merges parameters from this section directly with the configurations generated from internal templates, overriding and extending them as specified.

Warning

Modifying spec:services may result in the OpenStack deployment becoming unstable or entering an inconsistent state. This capability is intended solely for operators with expert-level knowledge of configuration parameters and their implications, and only in cases the spec:features section does not offer the required level of control. Mirantis assumes no responsibility for any issues arising from the use of the spec:services mechanism.

The spec:services structure

The general structure of the spec:services section is as follows:

spec:
  services:
    <SERVICE>:
      <COMPONENT>:
        values:
          ...

The keys of the spec:services structure

Key	Description
<SERVICE>	Corresponds to an entry in the spec:features:services list. Each service represents a group of Helm charts. For OpenStack services, these typically follow the official service type in the MOSK Identity service (OpenStack Keystone) catalog. To view all supported services, refer to OpenStack Operator resources.
<COMPONENT>	Represents the name of a specific chart within the group of <SERVICE> charts. Each service may include several charts for different components. For example, the compute service includes the nova chart for deploying MOSK Compute service (OpenStack Nova), the libvirt chart for deploying libvirt pods, and optionally the rabbitmq chart for deploying a dedicated RabbitMQ instance used exclusively by Nova. For OpenStack services, the <COMPONENT> usually follows the name of the service, such as nova or octavia.
values	Defines the changes to be applied to the chart. The structure under values must adhere to the chart’s default and accepted values. These values will be merged with the intended chart values just before being passed to Helm. You can inspect the structure of values in a live environment by checking any specific Helm release deployed by Rockoon: helm3 -n openstack get values --all <HELM-RELEASE> Alternatively, inspect the source code of Rockoon for the charts used by: OpenStack services Infrastructure services The values typically follow a standard schema: The main configuration file for an OpenStack service is defined in the conf.<COMPONENT> structure, for example, conf.nova. The structure beneath it follows the stanza <CONFIG-SECTION>.<CONFIG-OPTION>: <VALUE>. MOSK provides an opinionated set of default OpenStack configuration options. If these defaults do not meet your use case and you need to revert an option to its upstream default, use the "OPTION": "<None>" stanza to forcefully remove it from the configuration file. Deprecated Images are defined within the images.tags structure. For the appropriate image names, refer to the chart values. 0

0

Since MOSK 25.1, Mirantis strongly recommends defining custom images through the ConfigMap as described in Custom OpenStack images. This approach allows patched images to be applied automatically during an OpenStack version upgrade.

Configuration examples

Fine-tuning OpenStack Nova configuration

The following snippet illustrates how to reset the default_schedule_zone option to its upstream default value and set the volume_clear option to a custom value:

spec:
  services:
    compute:
      nova:
        values:
          conf:
            nova:
              DEFAULT:
                default_schedule_zone: <None>
              libvirt:
                volume_clear: none

The above example generates the following configuration file snippet:

[DEFAULT]
[libvirt]
volume_clear = none

Changing OpenStack Horizon configuration

The configuration of the MOSK Dashboard (OpenStack Horizon) differs from other service configurations because Horizon is a Django application. Its configuration file is not in the INI format but is instead a Python file that must adhere to valid Python syntax. This makes it trickier to populate from the section.key: value format commonly used in JSON or YAML.

Some options are managed in conf.horizon.local_settings.config and are rendered into the local_settings.py file with the template defined in conf.horizon.local_settings.template. Other options can be passed through the conf.horizon.local_settings.config.raw structure. In this structure, key: value YAML entries are translated into Pyhton by approximately the following procedure:

key = json.loads(json.dumps(yaml.loads((value))))

The resulted entries are appended to the end of the local_settings.py file, allowing you to override any default value.

For example, to prevent launching instances directly from images, and thus, effectively require boot-from-volume instances exclusively, use the following structure in the OpenStackDeployment custom resource:

spec:
  services:
    dashboard:
      horizon:
        values:
          conf:
            horizon:
              local_settings:
                config:
                  raw:
                    "LAUNCH_INSTANCE_DEFAULTS['disable_image']": true

Note

Before MOSK 25.2, the json.loads step in translating the YAML structure to Python code was omitted, effectively relying on close similarity between Python and JSON syntax for data structures. However, due to differences in the boolean syntax, it was impossible to set values to Python’s True or False.

Another example using complex data structure is adding an additional role, cloud-admin, alongside the default admin, which allows the user to access the Admin panels in the Dashboard:

spec:
  services:
    dashboard:
      horizon:
        values:
          conf:
            horizon:
              local_settings:
                config:
                  raw:
                    OPENSTACK_KEYSTONE_ADMIN_ROLES:
                      - admin
                      - cloud-admin

The above configuration renders as a Python list in the local_settings.py configuration file:

OPENSTACK_KEYSTONE_ADMIN_ROLES = ["admin", "cloud-admin"]

See also

Horizon official documentation: LAUNCH_INSTANCE_DEFAULTS