Install OpenStack with OpenStack-Ansible (AIO)

OpenStack has a reputation for being hard to install, and a multi-node production deployment genuinely is a serious engineering project. But you do not need a rack of servers to learn the platform or to evaluate it. OpenStack-Ansible (OSA) ships an All-In-One (AIO) mode that deploys every core service onto a single host, giving you a complete, API-compatible cloud you can poke at, break, and rebuild at will.

This tutorial walks through a clean AIO deployment of OpenStack 2025.2 on Ubuntu 24.04 LTS, the exact base that clouditiv runs in production. By the end you will have Keystone, Nova, Neutron, Glance, Cinder, Placement, and Horizon running on one machine, and you will know how to verify that each piece came up correctly.

Prerequisites and host sizing

An AIO build is resource hungry because it runs the entire control plane plus a compute node inside LXC containers on one box. Treat the following as minimums rather than targets:

• A dedicated Ubuntu 24.04 LTS host or VM (nested virtualization must be enabled if it is a VM).
• At least 8 CPU cores, 16 GB RAM (24 GB is far more comfortable), and 80 GB of free disk on the root filesystem.
• Root or passwordless sudo access, and outbound internet for package and container image downloads.

Start from a minimal install with nothing else competing for resources. Confirm the release and available memory before you begin:

lsb_release -a
free -h
nproc

Step 1: Prepare the host

Update the system, install git, and make sure the kernel is current. A reboot after upgrading avoids subtle issues where the running kernel and installed modules disagree.

sudo apt update && sudo apt dist-upgrade -y
sudo apt install -y git
sudo reboot

OSA expects to manage networking and storage itself, so do not pre-configure bridges. The bootstrap scripts create the br-mgmt, br-vxlan, br-storage, and br-vlan bridges for you.

Step 2: Clone OpenStack-Ansible

Clone the repository and check out the stable branch for the 2025.2 release. Working from a named stable branch keeps your deployment reproducible.

sudo git clone https://opendev.org/openstack/openstack-ansible /opt/openstack-ansible
cd /opt/openstack-ansible
sudo git checkout stable/2025.2

Step 3: Bootstrap Ansible and the AIO config

Two bootstrap scripts do the heavy lifting. The first installs a pinned Ansible plus all required roles and collections; the second generates the AIO inventory and the configuration under /etc/openstack_deploy.

sudo scripts/bootstrap-ansible.sh
sudo scripts/bootstrap-aio.sh

The AIO bootstrap writes openstack_user_config.yml and a set of user_variables.yml overrides describing a single-host topology. If you want to limit which services deploy, this is the moment to edit those files before the playbooks run. For a first build, the defaults are fine.

Step 4: Run the deployment playbooks

OSA deploys in three ordered phases. Run them from the playbooks directory. Each can take a while, so run them in a tmux or screen session so a dropped SSH connection does not kill the run.

cd /opt/openstack-ansible/playbooks
sudo openstack-ansible setup-hosts.yml
sudo openstack-ansible setup-infrastructure.yml
sudo openstack-ansible setup-openstack.yml

The phases map cleanly to responsibilities. setup-hosts.yml prepares the host and builds the LXC containers. setup-infrastructure.yml deploys the shared services — the Galera (MariaDB) database cluster, RabbitMQ, and memcached. setup-openstack.yml installs the OpenStack services themselves. On a decent machine the full sequence runs in roughly one to two hours.

What success looks like

At the end of each playbook Ansible prints a PLAY RECAP. You want every host line to show failed=0:

PLAY RECAP ******************************************************
aio1                       : ok=412  changed=176  unreachable=0  failed=0
aio1_galera_container-...  : ok=98   changed=41   unreachable=0  failed=0

Step 5: Verify the cloud

OSA creates a utility container with the OpenStack CLI and admin credentials already in place. Enter it and source the admin RC file:

sudo lxc-attach -n $(lxc-ls -1 | grep utility)
source /root/openrc
openstack endpoint list --service identity

Now run a few read-only commands to confirm the major services answer. If these return without errors, your control plane is healthy:

openstack service list
openstack compute service list
openstack network agent list
openstack hypervisor list

Glance should already contain a small Cirros test image that the bootstrap uploads, which is perfect for a first instance later:

openstack image list

Finally, reach the Horizon dashboard in a browser. By default it listens on the host's internal VIP over HTTPS. Find the admin password and the address with:

grep keystone_auth_admin_password /etc/openstack_deploy/user_secrets.yml
grep -m1 horizon /etc/openstack_deploy/openstack_inventory.json

Common errors and troubleshooting

Most first-run failures fall into a few buckets. Here is how to read them.

A playbook fails mid-run

Read the last fatal error, then simply re-run that single playbook. OSA tasks are idempotent, so a retry after a transient package-mirror or network hiccup almost always converges. Add -vv for more detail on the failing task.

Galera or RabbitMQ container will not start

This is the classic AIO snag and almost always means a previous run left a half-initialized database or stale Ansible facts. Re-running setup-infrastructure.yml usually fixes it; if a Galera container is truly wedged, destroying just that container and re-running the phase gives it a clean slate.

Out of memory or disk during setup-openstack

If the kernel OOM-killer fires or a task fails writing files, you have undersized the host. Add RAM and swap, free up disk, and re-run the failed playbook.

Tearing it down

Because AIO is meant for experimentation, OSA ships a teardown script that removes containers and configuration so you can start fresh:

cd /opt/openstack-ansible
sudo ./scripts/teardown.sh

Conclusion

An OpenStack-Ansible AIO build is the fastest honest way to get a real, full-featured OpenStack cloud in front of you. It is also a useful reality check: even the single-node path involves bridges, an LXC fleet, a Galera cluster, and a multi-phase Ansible run that you now have to keep patched, monitored, and backed up. Once it is running, the natural next steps are to create a project and user with Keystone and then launch your first instance.

Multiplying that operational effort across a resilient multi-node cluster is exactly the work clouditiv takes off your plate. We run this same stack — Ubuntu 24.04 and OpenStack 2025.2 — as a managed, sovereign private cloud with data kept in Germany, and our automation provisions a production-ready deployment in under 60 minutes. If you would rather consume OpenStack than operate it, explore our on-premise cloud and automated provisioning.