Kolla builds the OpenStack container images and leaves the deployment to Ansible

Image building and deployment are separate projects

Kolla's mission statement is given verbatim in the README.

To provide tools to create production-ready containers and to provide deployment tools for operating OpenStack clouds.

And the mechanism is a division of labour across four repositories, which the README lists as the four deliverables of the Kolla project.

| Deliverable | Repository | |---|---| | kolla | opendev.org/openstack/kolla | | kolla-ansible | opendev.org/openstack/kolla-ansible | | ansible-collection-kolla | opendev.org/openstack/ansible-collection-kolla | | kayobe | opendev.org/openstack/kayobe |

So this repository, the one being reviewed, is the image builder. The Ansible playbooks that deploy an OpenStack cloud are a different project. A reader who expects to find deployment playbooks here will not find them, and the README is clear that they are in kolla-ansible.

Kolla provides tools to create containers that can be run under either Docker or Podman, as well as Ansible playbooks to deploy OpenStack on baremetal or virtual machine to meet Kolla's mission.

The two runtime choices are worth a note, because Podman and Docker differ in rootless operation, in systemd unit generation and in how they handle a container's storage, and a project that supports both is removing a real decision from an operator.

The design philosophy is stated in the Overview. Kolla has out of the box defaults for a working basic deployment, and also implements complete customization. This model permits operators with minimal experience to deploy OpenStack quickly and as the operator's experience grows modify the OpenStack configuration to suit the operator's exact requirements.

That is a considered stance for an infrastructure project. The alternative, a configuration that exposes everything from the start, produces a deployment nobody can get through the door, and a configuration that exposes nothing produces a platform you cannot run in production.

The published images are explicitly not for production

There is a warning in the README that deserves to be read before anything else, and it is unusual to find it stated this plainly.

Kolla(-ansible) defaults to using these images in order to ease testing and demonstration setups, but they are not intended to be used beyond this. In particular, they do not undergo any security scrutiny. If you intend to deploy Kolla for production purposes, you are advised to create and curate your own set of images using the kolla tool.

The Kolla developers publish images in the Quay.io openstack.kolla namespace for every tagged release, so the images are easy to find and easy to pull, which is exactly why the warning is needed. A team that reads the release list and starts a production deployment from the published images is deploying code nobody has audited.

The advice is to build your own, and that is the kolla tool's job. The project description is precise about it, tool for building production-ready OpenStack and infrastructure containers, and the console script in the packaging metadata is kolla-build pointing at kolla.cmd.build:main.

So the workflow for a production deployment is, pull the templates, build the images yourself, push them to your own registry, and point the deployment at your registry. The build step is not optional ceremony, it is the point of the tool, and the published images exist so that a test environment can come up in an afternoon.

What the image build actually contains

The scope of the image set is large, and the README splits it into two lists.

The OpenStack services are Aodh, Barbican, Bifrost, Blazar, Ceilometer, Cinder, CloudKitty, Cyborg, Designate, Glance, Heat, Horizon, Ironic, Keystone, Magnum, Manila, Masakari, Mistral, Neutron, Nova, Octavia, Placement, Skyline with its APIServer and Console, Tacker, Trove and Watcher.

The infrastructure components are the ones that are not OpenStack but that a deployment needs. Collectd and Grafana for performance monitoring. Cron for log rotation. Etcd as a distributed key value store providing a reliable way to store data across a cluster of machines. Fluentd as an open source data collector for a unified logging layer. Gnocchi as a time-series storage database. Corosync and Pacemaker for HAcluster. HAProxy and Keepalived for high availability of services and their endpoints. MariaDB and Galera Cluster for highly available MySQL databases. Memcached as a distributed memory object caching system. MariaDB Backup for a hot backup of MySQL data while the system is running. Open vSwitch for use with Neutron. Opensearch to search, analyze and visualize log messages. Prometheus for systems monitoring and alerting. RabbitMQ as a broker messaging back end for communication between services. And Valkey Sentinel, which provides high availability for valkey along with monitoring, notification and configuration provider duties for clients.

The scale of that list is the actual value of the project. Assembling a working OpenStack in containers means solving the same integration problems for every service, the database schema, the message broker, the cache, the metrics pipeline, the logging pipeline, the high availability pair, and doing it for the twenty-six services that each have their own configuration file format. Kolla's contribution is having done that once.

The directory listing shows how the build is organised. The docker/ directory contains jinja2 templates for the Docker build system, etc/ contains a reference etc directory structure which requires configuration of a small number of configuration variables to build the images, and kolla/ contains the Python modules for the image build system. There is contrib/ with sample template override files, releasenotes/ with the release note for all added features, roles/ with the Ansible roles used in CI, specs/ containing the Kolla community's key arguments about architectural shifts in the code base, tests/ with functional testing tools and tools/ with tools for interacting with the built images.

The specs directory records decisions that were argued over

The specs/ directory is unusual and worth singling out, because it is a governance artefact rather than code. The README describes it as containing the Kolla community's key arguments about architectural shifts in the code base.

That is a design decision document, in the open, for changes that would otherwise be invisible. When a project changes the shape of its configuration, its directory layout or its build model, the argument that led to it is usually lost, and a year later somebody proposes the reverse without knowing it was tried. A specs/ directory with the arguments written down is the cheapest possible defence against that.

The same open discussion shows elsewhere in the repository. There is an AGENTS.md and a CLAUDE.md and a GEMINI.md at the top level, so the project is documenting for AI coding assistants as well as for contributors, and there is a .codespell-ignore, an .ansible-lint, a .yamllint, a .coveragerc, a .stestr.conf, a tox.ini and a zuul.d/ directory for the OpenStack continuous integration, which is Zuul.

The Python packaging is conventional OpenStack practice. The build system is pbr at 6.1.1 or newer, the project name is kolla, the version and the dependencies are dynamic, and the package data includes kolla with docker/**, which is how the templates ship inside the wheel. The console script is kolla-build.

There is also an oslo.config entry point.

[project.entry-points."oslo.config.opts"]
kolla = "kolla.opts:list_opts"

So the configuration options are registered with oslo.config, which is the OpenStack configuration library, and that is how the same options are exposed to the tools, the playbooks and the documentation from one definition.

The requirements list is short, which tells you how little the build tool itself does. pbr, Jinja2, GitPython, oslo.config and setuptools. The GitPython dependency is there because the tool reads git metadata to stamp the images.

Where Kolla is the wrong choice

The first wrong case is a team that wants a managed OpenStack. Kolla is the deployment layer for a cloud you operate yourself, on baremetal or virtual machines, with a container runtime, a database, a message broker and a lot of Ansible. A team that wants to run Nova and Glance as a service should not be assembling that stack.

The second wrong case is a team without container operations capacity. Kolla assumes you will run dozens of images in production, upgrade them, rebuild them when you need a patch, push them to a registry and pin the digests in your deployment. That is a real speciality, and if nobody on the team has done it, the deployment becomes the project.

The third wrong case is a team that only needs a couple of OpenStack services. Kolla provides images for the whole platform, and there is no supported way to take one image and ignore the rest, because the integration work is what the project is.

The fourth wrong case is a team that has decided against containers for their OpenStack. Kolla is specifically a container image builder, and while the underlying OpenStack services run fine on virtual machines with a package manager, Kolla is not the tool for that deployment model.

The fifth wrong case is a team that intends to start from the published images. The warning in the README is unambiguous, they do not undergo any security scrutiny, and the tool exists to make your own instead.

How it differs from deploying OpenStack with the DevStack

The comparison worth making is with DevStack, and the difference in approach is the entire purpose of the two projects.

DevStack targets quick development and CI environments rather than production clouds.

Kolla is the opposite. Its mission is production-ready containers and deployment tools for operating clouds, its build model is images you curate and push to your own registry, and its deployment path is Ansible playbooks applied to baremetal or virtual machines. The unit of deployment is a running cloud with a database, a broker, high availability, monitoring and logging, not a laptop.

The second difference is the operational model. Kolla is a system with upgrades, a registry, a set of pinned image digests and a configuration that you curate. The lifecycle is different in kind.

The third difference is what you inherit. Kolla gives you those services plus a layer of configuration, templating and defaults, which is what makes a coherent deployment possible and also what you have to understand when something behaves differently from upstream.

The fourth difference is scale of service coverage. Kolla lists twenty-six OpenStack services and the infrastructure components around them, and it is the completeness of that integration matrix that is the value, because the hard part of a containerised OpenStack is not any one service but the twenty-six ways they have to find each other.

Editorial conclusion

Kolla fits an infrastructure team running OpenStack in containers who want a supported image build path rather than hand-assembled images, and the separation between image building and deployment means a team can own its own image pipeline while using the project's playbooks. It does not fit a team that wants a hosted OpenStack, and it does not fit a team that intends to run the published images in production, since the README says explicitly that they do not undergo any security scrutiny. Before deploying, build your own image set with the kolla tool as the warning advises, read the specs/ directory for the architectural decisions the project treats as settled, and note that the project has no GitHub releases, with the last push on 2026-10-16 and the canonical repository at opendev.org rather than GitHub.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openstack/kolla on GitHub
4. Project website
5. README