Kolla Ansible

Kolla Ansible uses Prometheus as a framework to monitor the behavior and performance of nodes in large deployments. This monitoring approach covers both system-level and service-level characteristics.

Monitoring is achieved through three primary pillars:

1. Exposing the data: Using existing exporters or direct product support to provide data in Prometheus format.
2. Collecting and storing data: Configuring and running Prometheus instances to scrape and persist metrics.
3. Analyzing and reporting: Using tools like Grafana (configured with Prometheus as a data source) to visualize metrics and identify issues.

Key use cases include querying component performance, displaying system-wide dashboards, and monitoring the status of Kolla Ansible containers to identify deployment issues.

When deploying OpenStack in an active/active manner, choose your Keystone token format carefully:

• UUID Tokens: Recommended for initial HA deployments as they are easier to deploy in active/active environments.
• PKI Tokens: Provide better security but are more complex to deploy in an active/active configuration.

Kolla Ansible manages the etcd lifecycle by distinguishing between two bootstrapping modes based on the presence of existing data:

1. New Cluster Bootstrap: Triggered when Kolla Ansible detects no existing data on the etcd nodes. This bootstraps a clean multi-node cluster.
2. Existing Cluster Bootstrap: Triggered when data is detected. Kolla Ansible assumes a healthy cluster exists and will instead attempt to add a single node to that cluster.

Important Note on Configuration: Unlike most Kolla Ansible services, once an etcd cluster is bootstrapped, the service takes most of its configuration from the etcd database itself. Changes to bootstrap configuration may be ignored once the node has completed its initial bootstrap.

Since RabbitMQ 4.0, all queues are configured as quorum queues (highly available) by default. RabbitMQ also supports 'streams' as a high-performance alternative to 'fanout' queues.

To disable stream fanout, set om_enable_rabbitmq_stream_fanout: false.

Kolla Ansible automatically detects the host OS distribution to ensure compatibility. It deploys CentOS 7 containers on CentOS 7 hosts and CentOS 8 containers on CentOS 8 hosts to avoid kernel and userspace incompatibilities.

Image Tag Resolution Hierarchy

Kolla Ansible uses a hierarchy of variables to determine the correct container image tag. For a service like nova-compute, the resolution order is:

1. nova_compute_tag (Service-specific override)
2. nova_tag (Service group override)
3. openstack_tag (Intermediate OS-aware variable)
4. openstack_release (Default fallback)

On CentOS 8 hosts, openstack_tag defaults to {openstack_release}-centos8. On other distributions, it defaults to {openstack_release}.

Nova Cells require specific database and message queue configurations to function:

• Global Services: Require access to the API database, the cell0 database, and a global message queue.
• Per-cell Services: Each individual cell requires its own unique database and message queue instance.

Implementation in Kolla Ansible: Kolla Ansible supports deploying shared database clusters and message queue clusters. In this shared model, cells are partitioned using distinct database names and message queue virtual hosts.

The metadata_folder specified in keystone_identity_providers must contain JSON files named after the Issuer (URL-encoded). For example, if an Issuer is keycloak.example.org/auth/realms/idp.client, the file name must escape slashes as %2F.

Each provider requires three specific JSON files in that folder:

1. .client: Contains Service Provider credentials (client_id and client_secret).
2. .conf: Overrides OpenID Connect Apache2 plugin options. Can be an empty JSON {} if no overrides are needed.
3. .provider: Contains the full specification of the IdP (issuer, endpoints, supported scopes, etc.). You can use the JSON returned from the IdP's .well-known endpoint.

<IDP metadata directory>
  - keycloak.example.org%2Fauth%2Frealms%2Fidp.client
  - keycloak.example.org%2Fauth%2Frealms%2Fidp.conf
  - keycloak.example.org%2Fauth%2Frealms%2Fidp.provider