How an OpenStack Kolla-Ansible deployment is built and why it gets harder
Kolla-Ansible deploys OpenStack in Docker containers driven by Ansible, and OpenStack-Ansible is the other upstream option, deploying into LXC containers or directly on bare metal. The choice between them shapes the rest of the work: it determines how services are packaged, how hosts are laid out, how upgrades are sequenced and which operator skills the team needs on day two. Treat the tool selection as a design decision, not a formality, and document the reasons alongside the design.
The upstream OpenStack 2026.1 deployment guides are the reference for both tools, and the release in use decides which tool versions, configuration options and service behaviors apply. Confirm the release with your partner or internal team before the first commit, and record it in the repository. Reading a guide written for a different release is one of the most common ways a build drifts from its intended state before any host is touched.
The difficulty in Kolla-Ansible sits in the configuration rather than the playbooks. The inventory describes which hosts run which control, network, compute and storage groups, and the globals configuration sets the internal and external API addresses, the network interfaces, the container image settings and the enabled services. A mistake in one of these files can look harmless until a service fails to bind, a VIP lands on the wrong interface or a compute node joins the wrong network. Plan a review step for every change to these two files.
Host preparation and prerequisites carry much of the remaining risk. Each host needs consistent operating system packages, time synchronization, container runtime configuration, kernel parameters and disks prepared for the storage role. Network prerequisites include the management, tunnel, storage and external networks, with agreed VLANs, MTU values and bonding, all confirmed before deployment. Ask your team to validate these with pre-deployment checks, and to write down the answers to questions about the VIP address, the storage backend and the public endpoint names.
Keep every inventory, globals file, password store reference and custom configuration override in version control from the first day, including the commit that records the upstream release and image tags. Without this, the team cannot reproduce a deployment, review a change or roll back a failed reconfiguration with confidence. Store secrets in an encrypted form rather than in plain files, and agree on who approves merges to the production branch. This discipline costs little at the start and is the main protection against an environment that no one can rebuild later.
Which parts of a Kolla-Ansible deployment you configure and keep under version control
A Kolla-Ansible deployment is defined by a small set of text files rather than by hand-run commands. Together they describe which hosts play which roles, which OpenStack release and services are enabled, how individual services are tuned, and which passwords are generated or stored. Keeping these files in Git with review is what lets the team reproduce, audit and upgrade the cloud deliberately.
Ansible inventory and host roles
The inventory maps each physical host to roles such as control, network, compute, storage and monitoring. It decides where containers land and which hosts are treated as controllers, so a wrong group membership can move a database or a compute agent to the wrong machine. Your platform or infrastructure team should own it, and every change, such as adding a compute node or moving a network role, should go through a reviewed merge request with a plan of the expected host changes.
Globals configuration file
The globals file sets the OpenStack release to deploy, the container image settings, the virtual IP addresses and the list of enabled services. It is the single most consequential file in the repository, because a change to the release or to an enabled service alters what the next deployment run installs. Architects should own it, and reviewers should check that the release value and enabled services match the upgrade plan and the support window of the chosen release.
Per-service override files
Override files adjust individual services, such as API worker counts, service configuration parameters or logging, without editing the templates shipped with Kolla-Ansible. Service owners on the platform team usually edit them, and each change should name the service and the reason in the commit message. Keeping overrides small and explicit makes upgrades easier, because you can compare them against upstream defaults for each new release instead of reconstructing past decisions.
Secrets file for service passwords
The passwords file holds credentials for databases, message queues, service accounts and the administrative user. It must not be stored in plain text in an ordinary repository. Most teams keep it encrypted with Ansible Vault or in an external secrets store, restrict decryption to a small group of operators, and rotate values through a documented process. Confirm where the key material lives and who can read it before the first deployment.
Optional Ceph storage settings
If you back Glance, Cinder and Nova with Ceph, the inventory gains storage hosts and the globals file enables the matching storage services and pools. These settings change how volumes, images and ephemeral disks are placed, so they should be reviewed with the storage owner. The design of pools, boot-from-volume and backups is covered in the Ceph storage integration topic.
Review and environment separation
Inventories, globals and overrides differ between lab, staging and production, and drift between them is a common source of failed upgrades. Use one branch or directory per environment, promote changes in order, and require that the same files are tested before production. Confirm with your change board which reviewers must approve production merges and how the deployed state is recorded after each run.
Kolla-Ansible or OpenStack-Ansible: which fits your team
This table compares Kolla-Ansible and OpenStack-Ansible as described in the OpenStack 2026.1 deployment guides, one row per decision factor. Read each row against your team's skills and infrastructure standards, then confirm the operational costs with each project before you commit. The main takeaway is that the tool choice shapes your image pipeline, host layout and troubleshooting work, so make it before inventory design begins.
| Factor | Kolla-Ansible (Docker containers) | OpenStack-Ansible (LXC containers or bare metal) |
|---|---|---|
| Deployment model | Runs OpenStack services in Docker containers orchestrated with Ansible | Runs services in LXC containers or directly on bare metal, orchestrated with Ansible |
| Team skills that fit | Engineers comfortable with Docker images, container networking and registry operations | Engineers comfortable with LXC containers, Linux host administration and Ansible roles |
| Host OS standardization | Host OS needs a Docker runtime and a compatible kernel; confirm supported distributions for 2026.1 | Host OS is standardized around the supported distributions in the 2026.1 guide; confirm bare metal versus container placement per service |
| Appetite for image customization | Fits teams that build or patch their own container images and maintain a private registry | Fits teams that want the upstream role layout with less image-level work, and accept a more fixed service layout |
| Existing Ansible practice | Strong fit when your Ansible code already uses inventories, group variables and vault-encrypted secrets | Strong fit when your team already maintains Ansible roles and playbooks at similar depth |
| Image build and registry handling | Your team builds or pulls images, mirrors them into a registry and tracks each tag for every release | Less image handling; the main operational task is maintaining host and container templates |
| Container lifecycle | Containers are replaced during upgrades and restarts, so logs and state must live outside the container | Containers persist longer on hosts, so lifecycle is closer to traditional server management |
| Upgrade mechanics | Upgrades pull new images and roll containers; confirm the upgrade order for each SLURP path in the 2026.1 guide | Upgrades run Ansible role updates against hosts and containers; plan maintenance windows per host group |
| Troubleshooting depth | Needs container runtime skills (logs, exec, image inspection) in addition to OpenStack service knowledge | Needs LXC and host-level skills in addition to OpenStack service knowledge |
| Customization decision | Choose the standard layout unless a required change cannot be made through configuration overrides | Choose the standard layout unless a required change cannot be made through role variables and overrides |
| Timing of the decision | Decide before inventory design, since image naming and host groups depend on it | Decide before inventory design, since container placement and host groups depend on it |
How to build an OpenStack Kolla-Ansible deployment step by step
The sequence turns a prepared set of servers into a running OpenStack control plane, with each configuration change recorded in version control. It finishes with a working API endpoint that the later identity and storage integrations build on.
Prepare the deployment host and Python environment
The team builds a dedicated deployment host with SSH access to every target, then creates an isolated Python virtual environment and installs the Kolla-Ansible release chosen during design, along with its pinned dependencies. Keep this host under change control, because it holds the inventory, credentials and Ansible run history. Closing check: the Kolla-Ansible command runs from the virtual environment, reports the expected version, and reaches every target over SSH with key-based login.
Prepare the target hosts
Install the agreed operating system on each control, network, storage and compute host, then point every host at the same NTP source, since clock drift can break token validation and cluster coordination. Configure network bonds and VLANs to match the network design, and confirm that each disk the storage plan expects is present and unpartitioned. Closing check: every host shows synchronized time, resolves names consistently, and passes a manual connectivity test on each bond and VLAN before anything is installed.
Write the inventory and globals in Git
Write the multinode inventory that maps each host to its roles, then set the globals configuration for the internal and external virtual IP addresses, network interfaces, enabled services and container image source. Store both files and any service overrides in a Git repository with a branch per environment and peer review before merge. Closing check: a second engineer can rebuild the same environment from the repository alone, without asking the author for undocumented changes.
Generate and store secrets outside plain text
Generate service passwords and keys with the Kolla-Ansible password generator, which writes them into the passwords file, then move that file out of the working tree into an approved secrets store or encrypted vault. Decide who may read the deployment secrets and set a rotation schedule that matches your security policy. Commit only encrypted or reference values to Git. Closing check: a search of the repository finds no plain-text secret, and an authorized engineer can retrieve the values needed for a rebuild.
Run prechecks until they pass
Run the Kolla-Ansible precheck action against the full inventory, which validates host configuration, networking and service requirements before any container starts. Fix each failure in Git and rerun the check, so the repository stays the single record of the environment. Closing check: the precheck completes with no failed hosts for any enabled service, and the output is saved with the change record for this build.
Bootstrap the hosts and deploy the cloud
Run the bootstrap-servers action to install the container runtime and base dependencies on each host, then run deploy to start the OpenStack services as containers across the control, network and compute roles. Deployment runs long enough that the team should follow the log output and capture any failed task before rerunning it. Closing check: bootstrap completes on every host, deploy exits without failed tasks, and the containers on each host report a running state.
Run post-deploy and initial service tests
Run post-deploy to generate the admin credentials file, then source it on the deployment host and call the Keystone and Nova APIs to confirm authentication and service catalog entries. Create a test project, network, image and instance, and confirm the instance reaches the network and can be removed cleanly. The identity federation and Ceph storage integrations are added in the later steps covered by the sibling topics OpenStack SSO and identity integration and OpenStack Ceph storage integration. Closing check: API calls from the deployment host return valid responses.
What drives the effort and cost of a Kolla-Ansible deployment
This table lists the factors that change how much work a Kolla-Ansible deployment takes, why each one matters and what keeps it manageable. Read each row as a question to answer in your scope before asking for a quote. No fee or duration is given here, because the quote follows from a written scope.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of hosts and roles | Each controller, compute, network, storage and monitoring host needs its own inventory entry, bootstrap checks and validation. Mixed roles on shared hosts add ordering and resource conflicts. | Keep one reference inventory under version control, define host groups by role, and standardize host builds so every node starts from the same image and kernel settings. |
| Network topology complexity | Provider and tenant networks, bonded interfaces, VLAN trunks and separate management or API networks each need correct interface names, MTU values and Neutron mappings before the first deploy. | Document the network plan as a single table, agree the bonding and VLAN layout before deployment, and test connectivity on each host before running the playbooks. |
| Storage backend choice | Local LVM, NFS, Ceph or a vendor array each brings different Cinder driver settings, network paths and failure modes. Ceph in particular adds its own cluster design and sizing work. | Choose the backend before inventory work starts, limit the first release to one backend, and confirm driver support for your chosen OpenStack release with the vendor. |
| Number of enabled services | Every enabled service adds containers, database schemas, API endpoints, policies and tests to build and maintain. Optional services multiply the acceptance test list. | Enable only the services the workload needs at launch, and add others later through a tested change rather than enabling everything up front. |
| External integrations | Identity federation, LDAP, external monitoring, log forwarding and backup targets each need credentials, certificates, network rules and separate validation steps. | Sequence integrations after a working base cloud, name an owner for each external system, and confirm the integration approach against the relevant identity or monitoring documentation. |
| Customization of service configuration | Overrides to service configuration files, custom policies or patched containers must be tracked and retested on every upgrade, which raises the cost of each release cycle. | Keep overrides in the same version-controlled repository, minimize local patches, and record the reason for each override so it can be reviewed at upgrade time. |
| Number of environments | Lab, staging and production each need their own inventory, secrets and validation runs. Drift between them is a common source of rework at cutover. | Generate all environments from the same reference inventory with only the host and secret differences stored per environment, and promote changes through the same pipeline. |
| Compliance evidence requirements | Assessors may ask for configuration baselines, change records, access logs, TLS settings and test results. Gathering this after the build costs more than producing it during the build. | Write an acceptance test list before deployment, capture playbook output and configuration state as evidence at each stage, and confirm with your auditor which artifacts they expect. |
How the deployment changes for single node, highly available and air-gapped sites
A single node or lab deployment is useful for learning the Kolla-Ansible workflow, validating globals and password handling, and rehearsing upgrades before they touch production. Many parts can be simplified: one host can run every control plane service, a small set of virtual machines can stand in for compute nodes, and storage can be local or minimal. What must still match production is the software version, the configuration structure, the container image source, and the way changes are made through version-controlled inventories and configs.
A lab result does not prove production behavior because the failure modes that matter most are absent. A single node has no quorum, no virtual IP failover, no database replication lag, and no message queue partitions. Network topology, MTU, VLAN trunking, and storage latency are rarely representative either.
Checks to run in the lab:
- Confirm the lab uses the same OpenStack release and Kolla-Ansible branch the production plan specifies.
- Run the full deploy, reconfigure, and upgrade sequence from the repository, not from manual edits.
- Record which settings were simplified, so each one is listed as a gap to close before production.
- Confirm with the vendor or your own environment which services are supported on a single host.
Treat the lab as a rehearsal of process, not as evidence that the production design works.
A highly available multi-host deployment adds the planning that a single node skips. The inventory gains separate groups for control, network, compute, storage and monitoring hosts, and the control group must span several hosts so that API and database services can fail over. Shared endpoints are configured once in the globals so that every service publishes its API behind the same internal and external names, and a virtual IP address is reserved for each endpoint on the management network.
Virtual IP planning needs more care than the address itself. The internal and external VIPs must sit on subnets the team controls, must not collide with DHCP ranges, and must be reachable from every control host. Certificate subject names must match the endpoint names, and DNS records must point to the VIP rather than to any single host.
Checks to run for multi-host:
- Confirm the inventory groups match the Kolla-Ansible release documentation, with control hosts counted as the documentation requires.
- Reserve and document the internal and external VIPs, then test failover of each VIP between control hosts.
- Verify that endpoint DNS and certificate names resolve to the VIP for every consumer.
- Confirm which services need shared storage or a separate message queue cluster in your environment.
For control plane design, including database clustering, message queue layout and host failure behavior, use the separate high availability topic.
Air-gapped or restricted networks change how the deployment obtains everything it needs. Kolla-Ansible pulls container images and the deployment depends on Python packages and operating system packages, so each of these must be mirrored into an internal registry or repository before the first deploy. The mirror must hold the exact image tags and package versions used by the release, otherwise the team cannot reproduce a deploy or a rollback.
Offline dependency handling is a process, not a one-time copy. Every update to the release, the Kolla-Ansible branch, or a patch level needs a new mirror snapshot, a checksum record, and a review of what changed. Build hosts used to create images must also be isolated from the internet, and their inputs must be traceable to the internal mirror.
Checks to run for restricted networks:
- Build an inventory of every image and package the deploy and upgrade need, and confirm it against the release documentation.
- Test a complete deploy with outbound internet access blocked at the firewall, not just with a proxy setting.
- Confirm how the same version-controlled repository is promoted into the restricted network and which branch or tag is pinned there.
- Confirm with your security team how mirror contents are scanned and approved before import.
The same repository carries over: globals, inventories and overrides are reused, and only the registry and mirror endpoints change.
How to verify the OpenStack deployment works and fails safely
A Kolla-Ansible deployment is not finished when the playbook exits successfully. Verification should run in layers, each of which catches a different class of fault: the pre-deployment checks, the second run of the same playbooks, service health inside the containers, reachability of the API endpoints from the networks where clients will actually connect, and an end-to-end test that exercises the whole path. Plan these layers as a written checklist before the first production run, so that the same checks can be repeated after every change. Ask your implementation partner or internal team to name who runs each layer and where the results are stored.
Start with the Kolla-Ansible prechecks, which validate the inventory, host prerequisites and configuration before containers are changed. After a successful deploy, run the playbooks a second time against the same inventory and configuration. A healthy result is a run that reports no unexpected changes. Any task that still reports changed on the second pass means something is not converging, such as a file regenerated from a template with a non-deterministic value or a container restarted by a dependency. Investigate every such task before accepting the deployment, because drift at this stage becomes harder to explain after tenants are onboarded.
Next, check service health from the containers and their logs on each controller, network and compute host. Confirm that the expected containers are running, that restarts are not looping, and that logs contain no repeated authentication, database or message queue errors. Then test each API endpoint from the networks where clients will connect, not only from the deployment host. Endpoint TLS certificates, DNS names and firewall rules often pass local tests and fail from a tenant or administrative network. Record the exact commands and responses used, so a later reviewer can repeat them.
An end-to-end test launches a test instance with a known image, a project network, a volume and a floating address, then confirms console or SSH access, data persistence on the volume, and outbound and inbound connectivity. Then run a failure test: stop one controller or one compute host during a controlled window and confirm that the behavior matches the design. Confirm the expected failure behavior of your chosen high availability design with the vendor and OpenStack documentation for the exact release and with your own tests. Do not assume a database or message queue cluster fails over the way a generic cluster does. Record what happened to running instances, API calls and volumes, and do not run the failure test against tenant workloads.
Record evidence for every change: the exact OpenStack release and Kolla-Ansible version, the inventory and globals revision in version control, the commit or tag deployed, the prechecks and idempotence results, endpoint and end-to-end test outputs, and the failure test notes. Keep these records with the change ticket. To roll back a failed change, redeploy the last known good commit of the configuration and inventory, then rerun the verification layers and compare results to the recorded baseline. Rolling back containers without rolling back the configuration usually leaves the environment in a state that no one can reproduce, so treat version control as the rollback mechanism and test that procedure before it is needed.
Securing secrets, API endpoints and deployment access in Kolla-Ansible
A Kolla-Ansible deployment is only as secure as the material that drives it: the generated passwords, the globals and overrides files, the host that runs the deployer, and the API endpoints that tenants and operators reach. The controls below cover the deployment itself and the decisions the team must make about storing, reviewing and rotating that material. Wider cloud hardening is covered in the OpenStack security hardening topic.
Protect the generated passwords file
Kolla-Ansible generates a passwords file that holds service and database credentials for the whole cloud. Decide up front whether it lives in an encrypted repository, in a secrets manager that the deployer reads at run time, or in both. Confirm with the team who can read it, how it is backed up, and how a credential is rotated after an engineer leaves. Check the current Kolla-Ansible documentation for the supported way to rotate passwords before relying on it.
Restrict deployer and repository access
Anyone who can run the deployer or read the inventory can change configuration on every control plane and compute node. Limit deployer execution to a named group of engineers or a CI runner with a dedicated service identity. Apply repository access controls so that read access to globals, overrides and inventories is granted by role, and audit who holds it each quarter.
Enable TLS on public and internal endpoints
Keystone, Nova, Neutron, Glance, Cinder and Horizon all expose HTTP APIs that carry tokens and credentials. Plan TLS for both the public endpoint that users reach and the internal and admin endpoints that services use among themselves. The team, not the deployment tool, owns the certificate authority, issuance, renewal and key storage, so set those owners and renewal dates before the first deployment.
Limit SSH access to the deployment host
The host that runs Kolla-Ansible holds the SSH keys that reach every cloud node, so it is a high-value target. Restrict inbound SSH to a bastion or management network, require individual keys rather than shared accounts, and log sessions. Confirm which account Kolla-Ansible uses to reach each node and whether that account needs sudo rights, and keep those rights as narrow as the deployment allows.
Review globals and overrides through pull requests
Changes to globals.yml, per-host overrides and the inventory alter how the cloud is built and which services are exposed. Route each change through a pull request with at least one reviewer who did not write it, and require the review to check enabled services, endpoint addresses and TLS settings. Keep the approval record in the repository history so that a later audit can trace each configuration decision.
Confirm scope with the hardening topic
Several controls that protect an OpenStack cloud sit outside the deployment tool. Keystone policies, tenant network isolation and hypervisor hardening each need their own design and test plan. Treat this section as the deployment-side baseline and use the OpenStack security hardening topic to plan the remaining work, then confirm with the vendor documentation which settings the deployment tool supports.
What to monitor, back up, upgrade and document after go-live
After a Kolla-Ansible deployment goes live, the operating burden shifts from building the cloud to keeping its control plane healthy. Monitoring should cover four layers. First, the Docker service containers that Kolla-Ansible starts for each OpenStack service, including whether they restart, fail health checks or drift from the image versions in your deployment configuration. Second, API latency and error rates for the public and internal endpoints of Keystone, Nova, Neutron, Glance, Cinder and Horizon, since tenants often notice API trouble before any host alarm fires. Third, the RabbitMQ message queue and the MariaDB database, where slow queues or replication lag tend to surface as intermittent failures in provisioning. Fourth, host resources on controllers, network nodes and compute nodes: CPU, memory, disk latency and network errors. Confirm with your deployment team which exporters and dashboards they will set up, and which alert thresholds they propose, before handover.
Backups need two targets, and the second is easy to forget. The first is the OpenStack database, which holds the state of projects, instances, networks and volumes. Confirm how your team will take consistent dumps of the MariaDB databases, how often they run, where copies go and how long they are kept. The second is the configuration repository: the Kolla-Ansible globals file, the inventory, the per-service overrides and any custom policy or configuration files. Restoring the database without the exact configuration that produced the running containers can leave you with a cloud that cannot be redeployed cleanly. The same logic applies to the deployer's secrets, which Kolla-Ansible generates into a passwords file. Losing that file means losing the credentials needed to reconfigure services, so it must be backed up with the same care as the database, stored encrypted and access-controlled, and tested by restoring it into a lab environment.
Upgrades follow the OpenStack release cadence, and planning them early avoids forced changes later. Releases are published on a six-month cycle, and since the 2022 cadence change, upgrades are supported between SLURP releases as well as between adjacent releases. The recommended upgrade points are SLURP releases such as 2026.1 Gazpacho, released on 2026-04-01, and 2025.1 Epoxy, released on 2025-04-02. Stable branches are maintained for approximately 18 months, after which only SLURP releases remain in an unmaintained phase with no releases and reduced CI, before end of life. Check the current status of your release on the OpenStack releases site when you hand over, and confirm which release your Kolla-Ansible version targets. Your team should also understand that a Kolla-Ansible upgrade is a deployment change, so the backup set described above should be current before every upgrade run.
Handover should leave your team able to operate the cloud without the people who built it. The core set includes a runbook for routine operations such as adding compute nodes, rotating credentials and restarting containers, a runbook for backup and restore that has been tested, an incident playbook for controller and database failures, and an architecture record that explains the network layout, storage design, identity configuration and the reasons behind major choices. Architecture decision records are especially useful because they explain why a setting exists, which helps during future upgrades. Ask the deployment partner to deliver these as versioned documents alongside the configuration repository, and confirm who owns each one after handover.
The upgrade and support plan, including how each service is tested before and after a release change and what ongoing operations support covers, is set out in the OpenStack upgrades and support topic. Use this section as the checklist for day-to-day operations, and use that topic to plan the upgrade calendar, the test environments and the support model that fits your team.
OpenStack Kolla-Ansible deployment questions buyers ask before hiring help
How much does a Kolla-Ansible OpenStack deployment cost?
The cost depends on the scope agreed in writing, and no price list applies because DeployOpen quotes from that scope. Expect the bill to combine several parts: design work on services, hardware, networking and storage; the build and integration effort; testing and handover; and any ongoing support you choose. The main cost drivers are the number of OpenStack services in scope, the number of hosts and networks, whether Ceph storage is included, how many identity sources must be federated, and how much of your existing tooling must be integrated. Ask for a quote that separates one-time work from recurring items such as support retainers and upgrade work, and that lists what you must provide. Hardware, licenses for any third-party tools and your own staff time are usually costs you carry directly.
How long does it take to deploy OpenStack with Kolla-Ansible?
The timeline follows the written scope, so the duration cannot be stated before the scope is agreed. The drivers are the same ones that drive cost: how many services are deployed, how complex the network plan is, whether storage is built on Ceph, how many hardware types must be validated, and how quickly your team can approve designs and grant access. Delays often come from waiting on hardware delivery, firewall changes and decisions about identity integration rather than from the container deployment itself. Ask the partner for a phased plan with named milestones, the dependencies you own, and the acceptance tests that close each phase.
Can our in-house team deploy Kolla-Ansible without outside help?
Yes, a capable team can, but it needs several skills at once. Engineers should be comfortable with Linux administration, IP networking including VLANs, bonding and routing, Ansible playbooks and inventories, Docker container runtime behavior, and the core OpenStack services such as Keystone, Nova, Neutron, Glance, Cinder and Horizon. Storage and database skills matter once you add Ceph or highly available control planes. The harder work is usually day two: upgrades, certificate rotation, troubleshooting failed containers and keeping inventories under version control. Assess your team against those skills honestly, and consider a fixed-scope build with knowledge transfer if one or two of them are missing.
What does our organization need to provide for a Kolla-Ansible project?
Plan to provide the hardware, a written network plan, and access. Hardware should match the sizing in the agreed design, including controller, compute, network and storage nodes, with the firmware and BIOS settings your vendor recommends. The network plan needs address ranges, VLAN assignments, DNS, NTP, routing and firewall rules agreed in advance. Access means accounts on the hosts, a management path, change windows and a secure location for secrets. You also need named decision makers for identity, security, storage and change approval, because open design questions stall builds. Confirm each of these items in the written scope so that responsibilities are clear before work starts.
Should we choose Kolla-Ansible or OpenStack-Ansible for our cloud?
Choose based on how your team wants to package and operate services. Kolla-Ansible deploys OpenStack services in Docker containers using Ansible, which many teams find familiar if they already run container hosts. OpenStack-Ansible deploys in LXC containers or directly on bare metal, according to the OpenStack 2026.1 deployment guides. Consider your existing container tooling, how you plan to run upgrades, your team's Ansible experience and whether you want containerized services or direct host installs. Both are covered by upstream documentation, so the decision should rest on your operating model, not on a preference for one name. Ask a partner to document the trade-offs against your environment before committing.
What does a DeployOpen Kolla-Ansible engagement hand over?
Handover should be defined in the written scope and usually includes the deployed and tested cloud, the Ansible inventories and configuration under version control, documented network and storage designs, identity configuration, backup and restore procedures, and runbooks for common operations. You should also receive acceptance test results, a list of open issues and the access model used. DeployOpen plans, implements, documents and can support OpenStack in your own infrastructure, so the deliverables stay in your environment. Ask for the handover list before signing, and confirm who holds the repository, credentials and administrative accounts at project close.
Which Kolla-Ansible release should we deploy and how long will it be supported?
Choose a release that your planned upgrade path can support, and confirm the current maintained releases before you start. OpenStack has historically released on a six-month cycle, and upgrades are supported between SLURP releases as well as between adjacent releases. The 2026.1 Gazpacho release is a SLURP release, and 2025.1 Epoxy is also SLURP. Stable branches are maintained for approximately 18 months, after which only SLURP releases may enter an unmaintained phase before end of life. Ask the partner to map your target release against that window and against your expected upgrade schedule.
How DeployOpen scopes, builds, hands over and supports an OpenStack deployment
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including OpenStack deployed with Kolla-Ansible. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names the OpenStack services, release series and control plane layout to be deployed with Kolla-Ansible.
- Scope records the target hosts, network segments, storage backends and the identity provider the cloud will trust.
- Scope states which configuration files, inventories and passwords are versioned, and where the repository lives in your environment.
How we build
- Build runs in stages: host preparation, container images, control plane bootstrap, then compute node enrollment.
- Each stage is tested against the agreed acceptance checks before the next stage starts, with results recorded for your team.
- Configuration is kept in version-controlled inventories and globals files so every change can be reviewed and reproduced.
How we hand over
- Handover includes the inventory, configuration repository, deployment runbooks and the verification scripts used during build.
- Documentation covers how to add a compute node, rotate credentials and run a deployment or reconfiguration safely.
- Your operators walk through routine tasks, and open items are listed in writing so ownership is clear at sign-off.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped in writing separately from the build.
- Support plans can cover planning for upgrades between SLURP and adjacent releases, with testing per service before rollout.
- Confirm with us during scoping which release series and maintenance window your team needs covered, and how incidents are escalated.
