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]

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

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"]