Overriding default configuration¶

Role defaults¶

Every role has a file, defaults/main.yml which holds the usual variables overridable by a deployer, like a regular Ansible role. This defaults are the closest possible to OpenStack standards.

They can be overridden at multiple levels.

Group vars and host vars¶

OpenStack-Ansible provides safe defaults for deployers in its group_vars folder. They take care of the wiring between different roles, like for example storing information on how to reach RabbitMQ from nova role.

You can override the existing group vars (and host vars) by creating your own folder in /etc/openstack_deploy/group_vars (and /etc/openstack_deploy/host_vars respectively).

If you want to change the location of the override folder, you can adapt your openstack-ansible.rc file, or export GROUP_VARS_PATH and HOST_VARS_PATH during your shell session.

Role vars¶

Every role makes use of additional variables in vars/ which take precedence over group vars.

These variables are typically internal to the role and are not designed to be overridden. However, deployers may choose to override them using extra-vars by placing the overrides into the user variables file.

User variables¶

If you want to globally override variable, you can define the variable you want to override in a /etc/openstack_deploy/user_*.yml file. It will apply on all hosts.

config_template documentation¶

These are the options available as found within the virtual module documentation section.

module: config_template
version_added: 1.9.2
short_description: >
  Renders template files providing a create/update override interface
description:
  - The module contains the template functionality with the ability to
    override items in config, in transit, through the use of a simple
    dictionary without having to write out various temp files on target
    machines. The module renders all of the potential jinja a user could
    provide in both the template file and in the override dictionary which
    is ideal for deployers who may have lots of different configs using a
    similar code base.
  - The module is an extension of the **copy** module and all of attributes
    that can be set there are available to be set here.
options:
  src:
    description:
      - Path of a Jinja2 formatted template on the local server. This can
        be a relative or absolute path.
    required: true
    default: null
  dest:
    description:
      - Location to render the template to on the remote machine.
    required: true
    default: null
  config_overrides:
    description:
      - A dictionary used to update or override items within a configuration
        template. The dictionary data structure may be nested. If the target
        config file is an ini file the nested keys in the ``config_overrides``
        will be used as section headers.
  config_type:
    description:
      - A string value describing the target config type.
    choices:
      - ini
      - json
      - yaml

Example task using the config_template module¶

In this task the test.ini.j2 file is a template which will be rendered and written to disk at /tmp/test.ini. The config_overrides entry is a dictionary (hash) which allows a deployer to set arbitrary data as overrides to be written into the configuration file at run time. The config_type entry specifies the type of configuration file the module will be interacting with; available options are “yaml”, “json”, and “ini”.

- name: Run config template ini
  config_template:
    src: test.ini.j2
    dest: /tmp/test.ini
    config_overrides: "{{ test_overrides }}"
    config_type: ini

Here is an example override dictionary (hash)

test_overrides:
  DEFAULT:
    new_item: 12345

And here is the template file:

[DEFAULT]
value1 = abc
value2 = 123

The rendered file on disk, namely /tmp/test.ini looks like this:

[DEFAULT]
value1 = abc
value2 = 123
new_item = 12345

Discovering available overrides¶

All of these options can be specified in any way that suits your deployment. In terms of ease of use and flexibility it’s recommended that you define your overrides in a user variable file such as /etc/openstack_deploy/user_variables.yml.

The list of overrides available may be found by executing:

find . -name "main.yml" -exec grep '_.*_overrides:' {} \; \
    | grep -v "^#" \
    | sort -u

The following override variables are currently available:

Galera:

• galera_client_my_cnf_overrides
• galera_my_cnf_overrides
• galera_cluster_cnf_overrides
• galera_debian_cnf_overrides

Telemetry service (ceilometer):

• ceilometer_policy_overrides
• ceilometer_ceilometer_conf_overrides
• ceilometer_event_definitions_yaml_overrides
• ceilometer_event_pipeline_yaml_overrides
• ceilometer_pipeline_yaml_overrides

Block Storage (cinder):

• cinder_policy_overrides
• cinder_rootwrap_conf_overrides
• cinder_api_paste_ini_overrides
• cinder_cinder_conf_overrides

Image service (glance):

• glance_glance_api_paste_ini_overrides
• glance_glance_api_conf_overrides
• glance_glance_cache_conf_overrides
• glance_glance_manage_conf_overrides
• glance_glance_registry_paste_ini_overrides
• glance_glance_registry_conf_overrides
• glance_glance_scrubber_conf_overrides
• glance_glance_scheme_json_overrides
• glance_policy_overrides

Orchestration service (heat):

• heat_heat_conf_overrides
• heat_api_paste_ini_overrides
• heat_default_yaml_overrides
• heat_aws_rds_dbinstance_yaml_overrides
• heat_policy_overrides

Identity service (keystone):

• keystone_keystone_conf_overrides
• keystone_keystone_default_conf_overrides
• keystone_keystone_paste_ini_overrides
• keystone_policy_overrides

Networking service (neutron):

• neutron_neutron_conf_overrides
• neutron_ml2_conf_ini_overrides
• neutron_dhcp_agent_ini_overrides
• neutron_api_paste_ini_overrides
• neutron_rootwrap_conf_overrides
• neutron_policy_overrides
• neutron_dnsmasq_neutron_conf_overrides
• neutron_l3_agent_ini_overrides
• neutron_metadata_agent_ini_overrides
• neutron_metering_agent_ini_overrides

Compute service (nova):

• nova_nova_conf_overrides
• nova_rootwrap_conf_overrides
• nova_api_paste_ini_overrides
• nova_policy_overrides

Object Storage service (swift):

• swift_swift_conf_overrides
• swift_swift_dispersion_conf_overrides
• swift_proxy_server_conf_overrides
• swift_account_server_conf_overrides
• swift_account_server_replicator_conf_overrides
• swift_container_server_conf_overrides
• swift_container_server_replicator_conf_overrides
• swift_object_server_conf_overrides
• swift_object_server_replicator_conf_overrides

Tempest:

• tempest_tempest_conf_overrides

pip:

• pip_global_conf_overrides

Note

Possible additional overrides can be found in the “Tunable Section” of each role’s main.yml file, such as /etc/ansible/roles/role_name/defaults/main.yml.

Overriding .conf files¶

Most often, overrides are implemented for the <service>.conf files (for example, nova.conf). These files use a standard INI file format.

For example, you might want to add the following parameters to the nova.conf file:

[DEFAULT]
remove_unused_original_minimum_age_seconds = 43200

[libvirt]
cpu_mode = host-model
disk_cachemodes = file=directsync,block=none

[database]
idle_timeout = 300
max_pool_size = 10

To do this, you use the following configuration entry in the /etc/openstack_deploy/user_variables.yml file:

nova_nova_conf_overrides:
  DEFAULT:
    remove_unused_original_minimum_age_seconds: 43200
  libvirt:
    cpu_mode: host-model
    disk_cachemodes: file=directsync,block=none
  database:
    idle_timeout: 300
    max_pool_size: 10

You can also apply overrides on a per-host basis with the following configuration in the /etc/openstack_deploy/openstack_user_config.yml file:

compute_hosts:
  900089-compute001:
    ip: 192.0.2.10
    host_vars:
      nova_nova_conf_overrides:
        DEFAULT:
          remove_unused_original_minimum_age_seconds: 43200
        libvirt:
          cpu_mode: host-model
          disk_cachemodes: file=directsync,block=none
        database:
          idle_timeout: 300
          max_pool_size: 10

Use this method for any files with the INI format for in OpenStack projects deployed in OpenStack-Ansible.

Overriding .json files¶

To implement access controls that are different from the ones in a standard OpenStack environment, you can adjust the default policies applied by services. Policy files are in a JSON format.

For example, you might want to add the following policy in the policy.json file for the Identity service (keystone):

{
    "identity:foo": "rule:admin_required",
    "identity:bar": "rule:admin_required"
}

To do this, you use the following configuration entry in the /etc/openstack_deploy/user_variables.yml file:

keystone_policy_overrides:
  identity:foo: "rule:admin_required"
  identity:bar: "rule:admin_required"

Use this method for any files with the JSON format in OpenStack projects deployed in OpenStack-Ansible.

To assist you in finding the appropriate variable name to use for overrides, the general format for the variable name is <service>_policy_overrides.

Overriding .yml files¶

You can override .yml file values by supplying replacement YAML content.

For example, you might want to define a meter exclusion for all hardware items in the default content of the pipeline.yml file for the Telemetry service (ceilometer):

sources:
    - name: meter_source
    interval: 600
    meters:
        - "!hardware.*"
    sinks:
        - meter_sink
    - name: foo_source
    value: foo

To do this, you use the following configuration entry in the /etc/openstack_deploy/user_variables.yml file:

ceilometer_pipeline_yaml_overrides:
  sources:
      - name: meter_source
      interval: 600
      meters:
          - "!hardware.*"
      sinks:
          - meter_sink
      - name: source_foo
      value: foo