Deployment manifest

A deployment manifest allows a user to override MicroStack’s default configurations.

Manifests are supported by the following commands:

  • sunbeam cluster bootstrap
  • sunbeam cluster refresh
  • sunbeam enable

Note: This feature is currently only supported in channel 2023.2/edge of the openstack snap.

Note: For a how-to on using manifests see Managing deployment manifests.

A manifest file

A manifest is a YAML file that consists of two sections: deployment and software. It has the following structure:

deployment:
  <deployment configs>
software:
  <software configs>

Deployment configuration

Any infrastructure related configuration like hardware/networking required by MicroStack are specified in this section. The complete list of configuration options that can be set in this section are mentioned on the Interactive configuration prompts page. If this section is empty, the user will be asked all the questions.

Software configuration

The software configuration consists of three subsections: juju, charms, and terraform. The overall software configuration looks like this:

software:
  juju:
    bootstrap_options:
      - <str>
      - <str>
  charms:
    <charm>:
      channel: <str>
      revision: <int>
      config: <dictionary>
    ...
    ...
  terraform:
    <openstack-plan>:
      source: <Path>

juju section

This section allows users to pass bootstrap arguments to Juju.

Option Description
bootstrap_args List of arguments that will be passed to the juju bootstrap command

charms section

This section allows users to set specific versions of charm to be deployed and the charm configurations. This section is a dictionary of charm and its options. The options that can be set for each charm are described below.

Option Description
channel charm channel to use
revision charm revision to use
config charm configuration to set

Charm channel/revision and their configuration are set by default and are known to work together. Use all default values in production and introduce a new setting only when necessary. For example, only change the channel/revision to get a possible hot fix or change a configuration setting as per the local environment (e.g. Keystone LDAP URL). Available charms and their configuration options are listed on the Underlying projects and charms page.

It is recommended to test any customisation in a staging environment before applying them in production.

terraform section

This section allows users to set local Terraform plans. This section is a dictionary of Terraform plans and their options. The options that can be set for each plan are described below.

Option Description
source Local path of the terraform plan

This section is for demonstration and development purposes only.

Caution: There is significant risk of misconfiguration when using a local Terraform plan due to the fact that MicroStack depends heavily on the plan variables.

Sample manifest

Below is a sample deployment manifest. It is for demonstration purposes only.

The management_cidr and metallb options are part of the deployment configuration and Juju bootstrap options. Overrides for charms keystone-k8s and glance-k8s are part of the software configuration:

deployment:
  bootstrap:
    # Management networks shared by hosts (CIDRs, separated by comma)
    management_cidr: 192.168.29.0/24
  addons:
    # MetalLB address allocation range (supports multiple ranges, comma separated)
    metallb: 10.20.21.10-10.20.21.20
software:
  juju:
    bootstrap_args:
      - --agent-version=3.2.4
  charms:
    keystone-k8s:
      channel: 2023.2/candidate
    glance-k8s:
      channel: 2023.2/candidate
      revision: 66
      config:
        debug: True
  terraform:
    hypervisor-plan:
      source: /home/ubuntu/deploy-openstack-hypervisor

Is this meant to be - --agent-version=3.2.4 (one hyphen at the beginning instead of two) since the bootstrap_args is list[str]?

Thanks @nobuto, updated with single hyphen.

I understand that this is for the demonstrating purpose only, but still it was hard for me to figure out the actual manifest for testing. It seems that the following content is bare minimum to make it work. Without reading the source code, it was hard to discover. It would be good if the documentation covers those at least.

deployment:
  proxy:
    proxy_required: false
  bootstrap:
    management_cidr: 192.168.123.0/24
  addons:
    metallb: 192.168.123.81-192.168.123.90
  microceph_config:
    sunbeam-1.localdomain:
      osd_devices: /dev/vdc

Just for the record, here is my current manifest file for testing.

deployment:
  proxy:
    proxy_required: false
  bootstrap:
    management_cidr: 10.0.123.0/24
  addons:
    metallb: 10.0.123.81-10.0.123.90
  microceph_config:
    sunbeam-1.localdomain:
      # LP: #2065470, LP: #2065698
      osd_devices: /dev/vdc,/dev/vdd
    sunbeam-2.localdomain:
      osd_devices: /dev/vdc,/dev/vdd
    sunbeam-3.localdomain:
      osd_devices: /dev/vdc,/dev/vdd
  external_network:
    nic: enp9s0
    cidr: 10.0.123.0/24
    gateway: 10.0.123.1
    start: 10.0.123.51
    end: 10.0.123.80
    network_type: flat  # or vlan
    #segmentation_id:
  user:
    remote_access_location: remote
    run_demo_setup: true
    username: demo
    password: demo
    cidr: 192.168.1.0/24
    nameservers: 10.0.123.1
    security_group_rules: true
software:
  juju:
    bootstrap_args:
      - --debug
      - --model-default=test-mode=true
      - --model-default=disable-telemetry=true
      # LP: #2065490
      - --model-default=logging-config=<root>=INFO;unit=DEBUG
      # LP: #2065700
      - --model-default=ignore-machine-addresses=true

And it’s merged with /snap/openstack/current/etc/manifests/edge.yml before passed to --manifest.