Kolla Ansible Configuration¶
Kayobe relies heavily on Kolla Ansible for deployment of the OpenStack control plane. Kolla Ansible is installed locally on the Ansible control host (the host from which Kayobe commands are executed), and Kolla Ansible commands are executed from there.
Kolla Ansible configuration is stored in ${KAYOBE_CONFIG_PATH}/kolla.yml.
Configuration of Ansible¶
Ansible configuration is described in detail in the Ansible documentation.
In addition to the standard locations, Kayobe supports using an Ansible
configuration file located in the Kayobe configuration at
${KAYOBE_CONFIG_PATH}/kolla/ansible.cfg or
${KAYOBE_CONFIG_PATH}/ansible.cfg. Note that if the ANSIBLE_CONFIG
environment variable is specified it takes precedence over this file.
Kolla Ansible Installation¶
Prior to deploying containers, Kolla Ansible and its dependencies will be installed on the Ansible control host. The following variables affect the installation of Kolla Ansible:
kolla_ansible_ctl_install_typeType of Kolla Ansible control installation. One of
binary(PyPI) orsource(git). Default issource.kolla_ansible_source_urlURL of Kolla Ansible source code repository if type is
source. Default is https://opendev.org/openstack/kolla-ansible.kolla_ansible_source_versionVersion (branch, tag, etc.) of Kolla Ansible source code repository if type is
source. Default is the same as the Kayobe upstream branch.kolla_ansible_venv_extra_requirementsExtra requirements to install inside the Kolla Ansible virtualenv. Default is an empty list.
kolla_upper_constraints_fileUpper constraints file for installation of Kolla. Default is
{{ pip_upper_constraints_file }}, which has a default ofhttps://releases.openstack.org/constraints/upper/{{ openstack_branch }}.
Example: custom git repository¶
To install Kolla Ansible from a custom git repository:
$KAYOBE_CONFIG_PATH/kolla.yml¶kolla_ansible_source_url: https://git.example.com/kolla-ansible
kolla_ansible_source_version: downstream
Virtual Environment Extra Requirements¶
Extra Python packages can be installed inside the Kolla Ansible virtualenv, such as when required by Ansible plugins.
For example, to use the hashi_vault Ansible lookup plugin, its
hvac dependency can be installed using:
$KAYOBE_CONFIG_PATH/kolla.yml¶---
# Extra requirements to install inside the Kolla Ansible virtualenv.
kolla_ansible_venv_extra_requirements:
- "hvac"
Local environment¶
The following variables affect the local environment on the Ansible control
host. They reference environment variables, and should be configured using
those rather than modifying the Ansible variable directly. The file
kayobe-env in the kayobe-config git repository sets some sensible defaults
for these variables, based on the recommended environment directory structure.
kolla_ansible_source_pathPath to directory for Kolla Ansible source code checkout. Default is
$KOLLA_SOURCE_PATH, or$PWD/src/kolla-ansible.kolla_ansible_venvPath to virtualenv in which to install Kolla Ansible on the Ansible control host. Default is
$KOLLA_VENV_PATHor$PWD/venvs/kolla-ansible.kolla_config_pathPath to Kolla Ansible configuration directory. Default is
$KOLLA_CONFIG_PATHor/etc/kolla.
Global Configuration¶
The following variables are global, affecting all containers. They are used to
generate the Kolla Ansible configuration file, globals.yml, and also affect
Kolla image build configuration.
Kolla Images¶
The following variables affect which Kolla images are used, and how they are accessed.
kolla_base_distroKolla base container image distribution. Default is
centos.kolla_install_typeKolla container image type:
binaryorsource. Default isbinary.kolla_docker_registryURL of docker registry to use for Kolla images. Default is not set, in which case Dockerhub will be used.
kolla_docker_namespaceDocker namespace to use for Kolla images. Default is
kolla.kolla_docker_registry_usernameUsername to use to access a docker registry. Default is not set, in which case the registry will be used without authentication.
kolla_docker_registry_passwordPassword to use to access a docker registry. Default is not set, in which case the registry will be used without authentication.
kolla_openstack_releaseKolla OpenStack release version. This should be a Docker image tag. Default is
{{ openstack_release }}, which takes the OpenStack release name (e.g.rocky) on stable branches and tagged releases, ormasteron the Kayobemasterbranch.
For example, to deploy Kolla centos binary images with a namespace of
example, and a private Docker registry at registry.example.com:4000,
tagged with 7.0.0.1:
$KAYOBE_CONFIG_PATH/kolla.yml¶kolla_base_distro: centos
kolla_install_type: binary
kolla_docker_namespace: example
kolla_docker_registry: registry.example.com:4000
kolla_openstack_release: 7.0.0.1
The deployed ironic-api image would be referenced as follows:
registry.example.com:4000/example/centos-binary-ironic-api:7.0.0.1
Ansible¶
The following variables affect how Ansible accesses the remote hosts.
kolla_ansible_userUser account to use for Kolla SSH access. Default is
kolla.kolla_ansible_groupPrimary group of Kolla SSH user. Default is
kolla.kolla_ansible_becomeWhether to use privilege escalation for all operations performed via Kolla Ansible. Default is
falsesince the 8.0.0 Ussuri release.kolla_ansible_target_venvPath to a virtual environment on remote hosts to use for Ansible module execution. Default is
{{ virtualenv_path }}/kolla-ansible. May be set toNoneto use the system Python interpreter.
Context: Remote Execution Environment¶
By default, Ansible executes modules remotely using the system python
interpreter, even if the Ansible control process is executed from within a
virtual environment (unless the local connection plugin is used).
This is not ideal if there are python dependencies that must be installed
with isolation from the system python packages. Ansible can be configured to
use a virtualenv by setting the host variable ansible_python_interpreter
to a path to a python interpreter in an existing virtual environment.
The variable kolla_ansible_target_venv configures the use of a virtual
environment on the remote hosts. The default configuration should work in most
cases.
User account creation¶
Since the Ussuri release, Kayobe creates a user account for Kolla Ansible
rather than this being done during Kolla Ansible’s bootstrap-servers
command. This workflow is more compatible with Ansible fact caching,
but does mean that Kolla Ansible’s create_kolla_user variable cannot be
used to disable creation of the user account. Instead, set
kolla_ansible_create_user to false.
kolla_ansible_create_userWhether to create a user account, configure passwordless sudo and authorise an SSH key for Kolla Ansible. Default is
true.
OpenStack Logging¶
The following variable affects OpenStack debug logging.
kolla_openstack_logging_debugWhether debug logging is enabled for OpenStack services. Default is
false.
TLS Encryption of APIs¶
The following variables affect TLS encryption of the public API.
kolla_enable_tls_externalWhether TLS is enabled for the public API endpoints. Default is
no.kolla_external_tls_certA TLS certificate bundle to use for the public API endpoints, if
kolla_enable_tls_externalistrue. Note that this should be formatted as a literal style block scalar.kolla_external_fqdn_cacertPath to a CA certificate file to use for the
OS_CACERTenvironment variable in openrc files when TLS is enabled, instead of Kolla Ansible’s default.
The following variables affect TLS encryption of the internal API. Currently this requires all Kolla images to be built with the API’s root CA trusted.
kolla_enable_tls_internalWhether TLS is enabled for the internal API endpoints. Default is
no.kolla_internal_tls_certA TLS certificate bundle to use for the internal API endpoints, if
kolla_enable_tls_internalistrue. Note that this should be formatted as a literal style block scalar.kolla_internal_fqdn_cacertPath to a CA certificate file to use for the
OS_CACERTenvironment variable in openrc files when TLS is enabled, instead of Kolla Ansible’s default.
Example: enabling TLS for the public API¶
It is highly recommended to use TLS encryption to secure the public API. Here is an example:
$KAYOBE_CONFIG_PATH/kolla.yml¶---
kolla_enable_tls_external: yes
kolla_external_tls_cert: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
kolla_external_fqdn_cacert: /path/to/ca/certificate/bundle
Example: enabling TLS for the internal API¶
It is highly recommended to use TLS encryption to secure the internal API. Here is an example:
$KAYOBE_CONFIG_PATH/kolla.yml¶---
kolla_enable_tls_internal: yes
kolla_internal_tls_cert: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
kolla_internal_fqdn_cacert: /path/to/ca/certificate/bundle
Other certificates¶
In general, Kolla Ansible expects certificates to be in a directory configured
via kolla_certificates_dir, which defaults to a directory named
certificates in the same directory as globals.yml. Kayobe follows this
pattern, and will pass files and directories added to
${KAYOBE_CONFIG_PATH}/kolla/certificates/ through to Kolla Ansible. This
can be useful when enabling backend API TLS encryption, or providing custom CA
certificates to be added to the trust store in containers. It is also possible
to use this path to provide certificate bundles for the external or internal
APIs, as an alternative to kolla_external_tls_cert and
kolla_internal_tls_cert.
Note that Ansible will automatically decrypt these files if they are encrypted via Ansible Vault and it has access to a Vault password.
Example: adding a trusted custom CA certificate to containers¶
In an environment with a private CA, it may be necessary to add the root CA certificate to the trust store of containers.
$KAYOBE_CONFIG_PATH¶kolla/
certificates/
ca/
private-ca.crt
These files should be PEM-formatted, and have a .crt extension.
Example: adding certificates for backend TLS¶
Kolla Ansible backend TLS can be used to provide end-to-end encryption of API traffic.
$KAYOBE_CONFIG_PATH¶kolla/
certificates/
backend-cert.pem
backend-key.pem
See the Kolla Ansible documentation for how to provide service and/or host-specific certificates and keys.
Custom Global Variables¶
Kolla Ansible uses a single file for global variables, globals.yml. Kayobe
provides configuration variables for all required variables and many of the
most commonly used the variables in this file. Some of these are in
$KAYOBE_CONFIG_PATH/kolla.yml, and others are determined from other sources
such as the networking configuration in $KAYOBE_CONFIG_PATH/networks.yml.
Additional global configuration may be provided by creating
$KAYOBE_CONFIG_PATH/kolla/globals.yml. Variables in this file will be
templated using Jinja2, and merged with the Kayobe globals.yml
configuration.
Host variables¶
Kayobe generates a host_vars file for each host in the Kolla Ansible inventory. These contain network interfaces and other host-specific things.
kolla_seed_inventory_pass_through_host_varsList of names of host variables to pass through from kayobe hosts to the Kolla Ansible seed host, if set. See also
kolla_seed_inventory_pass_through_host_vars_map. The default is:kolla_seed_inventory_pass_through_host_vars: - "ansible_host" - "ansible_port" - "ansible_ssh_private_key_file" - "kolla_api_interface" - "kolla_bifrost_network_interface"
kolla_seed_inventory_pass_through_host_vars_mapDict mapping names of variables in
kolla_seed_inventory_pass_through_host_varsto the variable to use in Kolla Ansible. If a variable name is not in this mapping the kayobe name is used. The default is:kolla_seed_inventory_pass_through_host_vars_map: kolla_api_interface: "api_interface" kolla_bifrost_network_interface: "bifrost_network_interface"
kolla_overcloud_inventory_pass_through_host_varsList of names of host variables to pass through from Kayobe hosts to Kolla Ansible hosts, if set. See also
kolla_overcloud_inventory_pass_through_host_vars_map. The default is:kolla_overcloud_inventory_pass_through_host_vars: - "ansible_host" - "ansible_port" - "ansible_ssh_private_key_file" - "kolla_network_interface" - "kolla_api_interface" - "kolla_storage_interface" - "kolla_cluster_interface" - "kolla_swift_storage_interface" - "kolla_swift_replication_interface" - "kolla_provision_interface" - "kolla_inspector_dnsmasq_interface" - "kolla_dns_interface" - "kolla_tunnel_interface" - "kolla_external_vip_interface" - "kolla_neutron_external_interfaces" - "kolla_neutron_bridge_names"
kolla_overcloud_inventory_pass_through_host_vars_mapDict mapping names of variables in
kolla_overcloud_inventory_pass_through_host_varsto the variable to use in Kolla Ansible. If a variable name is not in this mapping the Kayobe name is used. The default is:kolla_overcloud_inventory_pass_through_host_vars_map: kolla_network_interface: "network_interface" kolla_api_interface: "api_interface" kolla_storage_interface: "storage_interface" kolla_cluster_interface: "cluster_interface" kolla_swift_storage_interface: "swift_storage_interface" kolla_swift_replication_interface: "swift_replication_interface" kolla_provision_interface: "provision_interface" kolla_inspector_dnsmasq_interface: "ironic_dnsmasq_interface" kolla_dns_interface: "dns_interface" kolla_tunnel_interface: "tunnel_interface" kolla_neutron_external_interfaces: "neutron_external_interface" kolla_neutron_bridge_names: "neutron_bridge_name"
Custom Group Variables¶
Group variables can be used to set configuration for all hosts in a group. They
can be set in Kolla Ansible by placing files in
${KAYOBE_CONFIG_PATH}/kolla/inventory/group_vars/*. Since this
directory is copied directly into the Kolla Ansible inventory, Kolla
Ansible group names should be used. It should be noted that
extra-vars and host_vars take precedence over group_vars. For
more information on variable precedence see the Ansible documentation.
Example: configure a Nova cell¶
In Kolla Ansible, Nova cells are configured via group variables. For example, to
configure cell0001 the following file could be created:
$KAYOBE_CONFIG_PATH/kolla/inventory/group_vars/cell0001/all¶---
nova_cell_name: cell0001
nova_cell_novncproxy_group: cell0001-vnc
nova_cell_conductor_group: cell0001-control
nova_cell_compute_group: cell0001-compute
Passwords¶
Kolla Ansible auto-generates passwords to a file, passwords.yml. Kayobe
handles the orchestration of this, as well as encryption of the file using an
Ansible Vault password specified in the KAYOBE_VAULT_PASSWORD environment
variable, if present. The file is generated to
$KAYOBE_CONFIG_PATH/kolla/passwords.yml, and should be stored along with
other Kayobe configuration files. This file should not be manually modified.
kolla_ansible_custom_passwordsDictionary containing custom passwords to add or override in the Kolla passwords file. Default is
{{ kolla_ansible_default_custom_passwords }}, which contains SSH keys for use by Kolla Ansible and Bifrost.
Configuring Custom Passwords¶
In order to write additional passwords to passwords.yml, set the kayobe
variable kolla_ansible_custom_passwords in
$KAYOBE_CONFIG_PATH/kolla.yml.
$KAYOBE_CONFIG_PATH/kolla.yml¶---
# Dictionary containing custom passwords to add or override in the Kolla
# passwords file.
kolla_ansible_custom_passwords: >
{{ kolla_ansible_default_custom_passwords |
combine({'my_custom_password': 'correcthorsebatterystaple'}) }}
Control Plane Services¶
Kolla Ansible provides a flexible mechanism for configuring the services that it deploys. Kayobe adds some commonly required configuration options to the defaults provided by Kolla Ansible, but also allows for the free-form configuration supported by Kolla Ansible. The Kolla Ansible documentation should be used as a reference.
Enabling Services¶
Services deployed by Kolla Ansible are enabled via flags.
kolla_enable_<service or feature>There are various flags that can be used to enable features. These map to variables named
enable_<service or feature>in Kolla Ansible. The default set of enabled services and features is the same as in Kolla ansible, except that Ironic is enabled by default in Kayobe.
Example: enabling a service¶
A common task is enabling a new OpenStack service. This may be done via the
kolla_enable_* flags, for example:
$KAYOBE_CONFIG_PATH/kolla.yml¶---
kolla_enable_swift: true
Note that in some cases additional configuration may be required to successfully deploy a service - check the Kolla Ansible configuration reference.
Service Configuration¶
Kolla-ansible’s flexible configuration is described in the
Kolla Ansible service configuration documentation.
We won’t duplicate that here, but essentially it involves creating files under
a directory which for users of kayobe will be $KOLLA_CONFIG_PATH/config. In
kayobe, files in this directory are auto-generated and managed by kayobe.
Instead, users should create files under $KAYOBE_CONFIG_PATH/kolla/config
with the same directory structure. These files will be templated using Jinja2,
merged with kayobe’s own configuration, and written out to
$KOLLA_CONFIG_PATH/config.
The following files, if present, will be templated and provided to
Kolla Ansible. All paths are relative to $KAYOBE_CONFIG_PATH/kolla/config.
Note that typically Kolla Ansible does not use the same wildcard patterns, and
has a more restricted set of files that it will process. In some cases, it may
be necessary to inspect the Kolla Ansible configuration tasks to determine
which files are supported.
File |
Purpose |
|---|---|
|
Aodh configuration. |
|
Extended Aodh configuration. |
|
Mariabackup configuration. |
|
Barbican configuration. |
|
Extended Barbican configuration. |
|
Blazar configuration. |
|
Extended Blazar configuration. |
|
Ceilometer configuration. |
|
Extended Ceilometer configuration. |
|
Cinder configuration. |
|
Extended Cinder configuration. |
|
CloudKitty configuration. |
|
Extended CloudKitty configuration. |
|
Designate configuration. |
|
Extended Designate configuration. |
|
Elasticsearch configuration. |
|
Fluentd filter configuration. |
|
Fluentd input configuration. |
|
Fluentd output configuration. |
|
MariaDB configuration. |
|
Glance configuration. |
|
Extended Glance configuration. |
|
Global configuration for all OpenStack services. |
|
Gnocchi configuration. |
|
Extended Gnocchi configuration. |
|
Grafana configuration. |
|
Extended Grafana configuration. |
|
Main HAProxy configuration. |
|
Modular HAProxy configuration. |
|
Heat configuration. |
|
Extended heat configuration. |
|
Extended horizon configuration. |
|
InfluxDB configuration. |
|
Ironic inspector configuration. |
|
Ironic configuration. |
|
Extended ironic configuration. |
|
Kafka configuration. |
|
Extended Kafka configuration. |
|
Extended keepalived configuration. |
|
Keystone configuration. |
|
Extended keystone configuration. |
|
Magnum configuration. |
|
Extended magnum configuration. |
|
Manila configuration. |
|
Extended manila configuration. |
|
Extended MariaDB configuration. |
|
Masakari configuration. |
|
Extended masakari configuration. |
|
Extended Monasca configuration. |
|
Murano configuration. |
|
Extended murano configuration. |
|
Neutron configuration. |
|
Neutron ML2 configuration. |
|
Extended neutron configuration. |
|
Nova configuration. |
|
Extended nova configuration. |
|
Octavia configuration. |
|
Extended Octavia configuration. |
|
Prometheus configuration. |
|
Sahara configuration. |
|
Extended sahara configuration. |
|
Extended Storm configuration. |
|
Extended swift configuration. |
|
Zookeeper configuration. |
|
Extended Zookeeper configuration. |
