-
Notifications
You must be signed in to change notification settings - Fork 1
Comparison with Other OpenStack Deployment Tools
OpenStack has always been notoriously difficult to deploy. Over the years, the community and various vendors have built a wide range of tools to tackle this problem — each with a different target audience, architecture, and set of trade-offs. This page explains why these tools exist, what each one does, and how DeployStack fits into the picture.
OpenStack is natively designed for multi-node production environments: a controller node, one or more compute nodes, storage nodes, and a dedicated network node — all configured separately and interconnected. Installing it by hand means editing dozens of configuration files, setting up databases, message brokers, virtual network bridges, and service endpoints. Even for an experienced engineer, a manual deployment can take days.
This complexity gave rise to an entire ecosystem of deployment tools, each trying to solve a different slice of the problem.
Target: OpenStack core developers
Approach: Shell scripts that install and configure all services from source on a single machine
Devstack was the original single-node solution. It is fast to set up and gives developers a running OpenStack environment to test patches and new features against. However, it is explicitly not meant for production — the installation is unstable across reboots, leaves the system in a "dirty" state, and offers little abstraction over the raw configuration files. It is also entirely Ubuntu/RHEL-centric and tied to the upstream development cycle.
Target: Red Hat / CentOS users wanting a quick single-node or small multi-node setup
Approach: Puppet-based installer driven by an answers file
Packstack was Red Hat's answer to Devstack for non-developers. It uses Puppet manifests under the hood and generates an answers file that the user fills in before running the deployment. It was widely used in the RHEL/CentOS ecosystem but has been largely deprecated in favour of TripleO and later OpenStack Ansible. It is not compatible with Debian-based systems.
Target: Production multi-node deployments, primarily Red Hat environments
Approach: Deploys OpenStack using OpenStack itself — an "undercloud" manages the deployment of the "overcloud"
TripleO is one of the most sophisticated deployment tools ever built for OpenStack. It uses Ironic for bare metal provisioning, Heat for orchestration, and a full undercloud OpenStack to manage the lifecycle of the production overcloud. The result is an extremely powerful and production-grade system — but the learning curve is steep and the setup time is measured in hours, even for experienced engineers. It has been superseded by OpenStack Ansible and Kolla-Ansible for most use cases and is no longer actively developed.
Target: Production multi-node deployments, DevOps teams
Approach: Deploys all OpenStack services as Docker containers, orchestrated via Ansible
Kolla-Ansible is currently one of the most popular deployment tools for production OpenStack. It packages every service in a container, making upgrades, rollbacks, and troubleshooting significantly easier than package-based approaches. It supports both single-node and multi-node deployments and offers a high degree of customization through its globals.yml configuration file. However, it requires solid knowledge of both Ansible and Docker, and the initial configuration is far from trivial — even a minimal single-node deployment requires setting up inventory files, network interface mappings, and service selections before a single command can be run.
Target: Enterprise production deployments, Canonical customers
Approach: Deploys OpenStack services as Charms (reusable software packages) managed by the Juju controller, running in LXC containers
Juju is Canonical's answer to production-grade OpenStack deployment. It models the entire infrastructure as a graph of interconnected "charms" — each charm representing a service or component — and the Juju controller manages their lifecycle. The result is highly flexible and supports day-2 operations like scaling, upgrades, and HA configuration. However, Juju requires a dedicated controller node, a deep understanding of the Charm ecosystem, and significant upfront investment before anything is running.
Target: Developers and testers wanting a quick single-node OpenStack
Approach: Snap package bundling all core OpenStack services
MicroStack was Canonical's attempt to make single-node OpenStack as easy as snap install microstack. In theory, it bundles Keystone, Nova, Neutron, Glance, and Cinder in a single snap and initialises them with one command. In practice, it has significant limitations:
-
Cinder volumes do not work out of the box. The LVM backend is not enabled by the standard
microstack init --auto --controlcommand — it requires an additional--setup-loop-based-cinder-lvm-backendflag that is marked as experimental and is known to fail in many configurations. - Instances have no internet access by default. Neutron is configured minimally, and the external bridge is not connected to the physical network automatically. Getting floating IPs and internet routing to work requires manual steps that are not trivial for newcomers.
- Locked into Snap. All configuration files are buried inside the snap, making customisation difficult.
- Archived. The original MicroStack repository was archived in March 2024 and superseded by Sunbeam, which is still in early development.
Target: Developers, testers, and anyone who wants a fully functional single-node OpenStack without manual configuration
Approach: Python-based deployment tool that auto-detects the system, generates a configuration, and deploys a complete OpenStack environment
DeployStack was born out of the gap between tools like Devstack (too dirty, developer-only) and Kolla-Ansible/Juju (too complex for a single node). It takes a different approach: one command, a few minutes, and you have a genuinely working OpenStack — not just installed, but configured end-to-end:
- Automatic network discovery: the tool detects the active interface, extracts IP, netmask, gateway, and CIDR automatically, and uses that information to configure the OVS bridge for Neutron. Instances have internet access immediately after deployment.
- Cinder with LVM ready to use: both loopback and physical volume backends are supported and configured automatically. No extra flags or manual steps needed.
- Choice of network driver: OVS or OVN, selectable in the configuration file.
- Horizon included by default: the dashboard is installed and accessible immediately after deployment.
-
Not locked into any packaging system: written in Python, installable on any Debian-based system, with a
.debpackage coming soon.
| Feature | Devstack | Packstack | TripleO | Kolla-Ansible | Juju | MicroStack | DeployStack |
|---|---|---|---|---|---|---|---|
| Single-node support | ✅ | ✅ | ✅ | ✅ | ✅ | ||
| Multi-node support | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ |
| Debian/Ubuntu support | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ |
| No prior expertise required | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | |
| Cinder works out of the box | ✅ | ✅ | ✅ | ✅ | ✅ | ||
| Instances have internet access OOB | ✅ | ✅ | ✅ | ❌ | ✅ | ||
| Automatic network discovery | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| OVS / OVN choice | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ✅ |
| Horizon included | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Production-grade | ❌ | ✅ | ✅ | ✅ | ❌ | ||
| Actively maintained | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ |
⚠️ = partial support or requires additional manual steps ❌ = No native support ✅ = Natively supported
DeployStack is not trying to replace Kolla-Ansible or Juju for production environments — those tools exist for a reason and do their job well. DeployStack targets the space that has historically been underserved: a single node, working out of the box, for someone who wants to use OpenStack rather than spend days configuring it.
The trade-off is transparency: DeployStack achieves its "works immediately" goal by making deep, invasive changes to the host system — reconfiguring the network, creating OVS bridges, setting up LVM volumes, and installing a large number of system packages. The host effectively becomes dedicated to OpenStack after deployment. Tools like Kolla-Ansible are far less invasive thanks to containerization, but require significantly more expertise to set up.
For issues or contributions, visit the project repository.