📦 Deploying OpenStack with Kolla-Ansible: A Practical Guide

If you’ve ever hand-installed OpenStack from packages, you know the special despair of getting twelve services, their databases, message queues, and config files to agree with each other. Kolla-Ansible exists to end that. It ships every OpenStack service as a container image and uses Ansible to deploy and configure the whole cloud from a handful of YAML files.

I’ve stood up production clouds both ways, and Kolla-Ansible is how I’d do it today. Here’s a practical walkthrough — the parts that matter and the parts that bite.

What Kolla-Ansible actually gives you

Two things: Kolla builds (or pulls) Docker images for each OpenStack service, and Kolla-Ansible orchestrates deploying those containers and rendering their configs. The payoff is repeatability — your entire cloud is described in globals.yml, an inventory, and an optional passwords.yml. Rebuild a controller and you get a byte-identical deployment.

The mental shift: you no longer edit /etc/nova/nova.conf on a host. You edit config templates and re-run the deploy. Hand-edits get wiped on the next run. Embrace it.

Step 1: Prepare the deploy host and nodes

On a clean Ubuntu/Rocky deploy host:

python3 -m venv /opt/kolla && source /opt/kolla/bin/activate
pip install 'ansible-core>=2.16'
pip install git+https://opendev.org/openstack/kolla-ansible@stable/2024.1
kolla-ansible install-deps

Copy the example config into place:

mkdir -p /etc/kolla
cp -r /opt/kolla/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/
cp /opt/kolla/share/kolla-ansible/ansible/inventory/multinode .

Every target node needs SSH access, a second NIC (or VLAN) for the OpenStack network, and Python. That’s it — no pre-installed OpenStack packages.

Step 2: The config that actually matters in globals.yml

globals.yml is where 90% of your decisions live. The non-negotiables:

kolla_base_distro: "ubuntu"
openstack_release: "2024.1"

# The two networks that trip everyone up:
network_interface: "eth0"            # internal API / management
neutron_external_interface: "eth1"   # bare, no IP — Neutron owns it

kolla_internal_vip_address: "10.0.0.250"   # a free IP, becomes the VIP

enable_haproxy: "yes"
enable_neutron_provider_networks: "yes"

The two mistakes I see most:

• neutron_external_interface has an IP configured. It must be a bare L2 interface — Neutron takes it over. If it has an IP, external networking won’t work.
• kolla_internal_vip_address is already in use. It must be a free IP on the management network; HAProxy/keepalived claims it as the VIP. Pick an address outside your DHCP range.

Step 3: Generate passwords and run the bootstrap

kolla-genpwd                 # fills /etc/kolla/passwords.yml
kolla-ansible bootstrap-servers -i ./multinode
kolla-ansible prechecks -i ./multinode

Never skip prechecks. They catch the bare-interface mistake, insufficient RAM, kernel modules missing, and time skew before you’ve deployed anything. A clean prechecks run is the single best predictor of a clean deploy.

Step 4: Deploy and bootstrap the cloud

kolla-ansible deploy -i ./multinode
kolla-ansible post-deploy -i ./multinode

post-deploy writes /etc/kolla/admin-openrc.sh. Source it and verify:

source /etc/kolla/admin-openrc.sh
openstack service list
openstack network agent list
docker ps --format '{{.Names}}\t{{.Status}}' | grep -i unhealthy

That last command is your health bellwether — any container marked unhealthy is where to start digging in /var/log/kolla/<service>/.

Step 5: Day-two operations

The same tooling runs your whole lifecycle:

• Add a compute node: add it to the inventory, run kolla-ansible deploy --limit <newhost>.
• Change a config: edit /etc/kolla/config/<service>.conf, run kolla-ansible reconfigure.
• Upgrade: bump openstack_release, pull new images, run kolla-ansible upgrade.

The custom-config mechanism is the key day-two skill. Drop a file in /etc/kolla/config/nova.conf and Kolla merges it into the rendered config — that’s how you make persistent changes the supported way instead of hand-editing inside containers.

Where AI fits in the workflow

Kolla-Ansible failures are usually buried in long Ansible output. I pipe the failed task’s output into an LLM and ask:

“Here is the failing Ansible task and error from a kolla-ansible deploy. Tell me the most likely root cause, which globals.yml or inventory setting is implicated, and the read-only command to confirm it before I change anything.”

It’s quick at spotting “this is a VIP-already-in-use error” or “this container can’t reach RabbitMQ” from the noise. I also use it to draft the initial globals.yml for a new topology and then review every line myself. I keep these deploy-debugging prompts with my other OpenStack prompts.

What bites in production

A few hard-won lessons:

• Container images and config drift. Pin openstack_release and your image registry. “Latest” in production is how you get a surprise mid-incident.
• HAProxy VIP failover. Test keepalived failover deliberately before go-live, not during an outage.
• Logs live in containers. Get comfortable with /var/log/kolla/ and docker logs <service> early.
• Reconfigure is not free. It restarts services. Plan reconfigures like any change with downtime.

Kolla-Ansible turns OpenStack from a multi-day artisanal install into a repeatable, version-controlled deployment. Treat globals.yml as code, never hand-edit inside containers, and run prechecks every time. For more deployment and upgrade prompts, see our prompt library.

AI-suggested configs are assistive, not authoritative. Run prechecks and review every generated value before deploying.