Deploying with Kolla-Ansible · Prasanta Kumar Behera

Deploy OpenStack as containers with Kolla-Ansible: inventory and globals.yml, generated passwords, the deploy workflow, highly available control planes behind a VIP, service config overrides, and the safe way to run upgrades.

Why containers for OpenStack?

A classic OpenStack install is dozens of services with packages, config files and dependencies on every controller. Kolla packages each service as a container image; Kolla-Ansible uses Ansible to place those containers on hosts, generate their configuration and run them. The result is repeatable deployments, simple upgrades (swap images) and clear separation between services.

Instead of building a restaurant kitchen from loose parts every time, Kolla gives you ready-made kitchen modules: a pizza oven unit, a dishwasher unit, a fridge unit. Kolla-Ansible is the floor plan and installation crew that puts each module in the right place and plugs it in the same way every time.

The pieces you edit

File	Purpose
Inventory (`multinode`)	Which hosts are `control`, `network`, `compute`, `storage`, `monitoring`
`/etc/kolla/globals.yml`	The main settings: release, interfaces, VIP, which services to enable
`/etc/kolla/passwords.yml`	Every service password, generated by `kolla-genpwd` (keep it secret and backed up)
`/etc/kolla/config/`	Overrides merged into generated service configs

A minimal globals.yml:

kolla_base_distro: "ubuntu"
openstack_release: "2025.1"              # match the Kolla-Ansible version you installed
network_interface: "eth0"                # API / management network
neutron_external_interface: "eth1"       # external (provider) network, no IP on it
kolla_internal_vip_address: "10.0.0.250" # VIP held by keepalived on the controllers
enable_haproxy: "yes"
enable_cinder: "yes"
enable_cinder_backend_lvm: "no"          # e.g. use Ceph instead (external Ceph settings)
neutron_plugin_agent: "ovn"

The Kolla-Ansible version you install decides which OpenStack release it deploys. Check the documentation for that release for supported host OSes and Ansible versions.

Deploying

$ kolla-genpwd
$ kolla-ansible install-deps
$ kolla-ansible bootstrap-servers -i multinode
$ kolla-ansible prechecks -i multinode
$ kolla-ansible deploy -i multinode
$ kolla-ansible post-deploy -i multinode

Older releases put the inventory before the command (kolla-ansible -i multinode deploy); follow the syntax in your version's docs.

post-deploy writes admin credentials under /etc/kolla/ (admin-openrc.sh, and clouds.yaml in recent releases). The all-in-one inventory deploys everything on one host: ideal for a lab.

High availability

With three controllers:

keepalived holds the internal (and external) VIP on one controller; HAProxy on each controller load-balances API traffic to all of them.
MariaDB Galera replicates the databases across controllers (a quorum of 3).
RabbitMQ runs as a cluster with replicated queues (quorum queues in recent releases).

Losing one controller should be invisible to users. Losing two breaks quorum, which is why you need three, not two.

Day 2: overrides, reconfigure, upgrade

Never edit config inside containers (it's lost on the next run). Put overrides in /etc/kolla/config/nova.conf, /etc/kolla/config/nova/nova-compute.conf, or per host, then kolla-ansible reconfigure --tags nova.
Keep the whole /etc/kolla directory (except secrets, or with them encrypted) in Git.
Upgrades: read the release notes → back up the databases → run on staging → change openstack_release and install the matching Kolla-Ansible → pull → upgrade. Upgrade one release at a time unless the release notes support skipping (SLURP releases allow skipping one release in recent OpenStack versions).

Try it: an all-in-one cloud (lab VM with 2 NICs, 8+ GB RAM)

Follow your release's quickstart: create a virtualenv, install Kolla-Ansible, copy the example config and the all-in-one inventory.
Set globals.yml (a spare IP on your network as the VIP; the second NIC as neutron_external_interface), run kolla-genpwd, then bootstrap, prechecks, deploy and post-deploy.
Source the admin credentials, run openstack service list and openstack compute service list, and create a network, image and instance (lessons 03–05).
List the containers (docker ps or podman ps) and find each service's logs under /var/log/kolla/.
Add a nova.conf override (e.g. cpu_allocation_ratio), run reconfigure --tags nova, and confirm the setting in the running container's config.

Going deeper: running Kolla in production

Separate networks for API/management, tunnel (overlay), storage and external; Kolla has an interface setting for each.
Use external Ceph for Glance, Cinder and Nova, and deploy monitoring (Prometheus exporters are available as Kolla services).
Pin image tags and run a local registry mirror so deploys don't depend on the internet.
Alternatives: OpenStack-Ansible (LXC/venv-based), OpenStack-Helm (on Kubernetes), and vendor distributions. Pick one and stay consistent.

Recap

Kolla images + Kolla-Ansible playbooks = containerised, repeatable OpenStack.
Edit inventory, globals.yml, passwords.yml (generated) and /etc/kolla/config overrides; keep them in Git.
Deploy: genpwd → bootstrap-servers → prechecks → deploy → post-deploy.
HA: keepalived VIP + HAProxy, Galera and RabbitMQ clusters on three controllers.
Change config with reconfigure; upgrade with a tested, backed-up, one-release-at-a-time process.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.