OpenStack Support & Upgrade Planning
Last reviewed by Tyler Eastridge
AceMQ gives teams that already run OpenStack engineers for the control plane: the RabbitMQ message bus and the database the OpenStack services depend on, upgrade planning across SLURP and non-SLURP releases, and Kolla-Ansible or OpenStack-Helm deployments. AceMQ engineers lead and partner OpenStack specialists join the work. AceMQ supports the clouds you run. It builds no new private clouds, sells no distribution and produces no OpenStack patches.
A senior engineer, not an SDR. No sales sequence attached.
Without a new platform or a rebuildFor production incident cover, see AceMQ OpenStack 24/7 support.
Customers
Partners
The Problem
Seven OpenStack problems operators run into, from API calls that hang with every service healthy to an upgrade path nobody has written down. If one describes your quarter, that is where the review starts.
API calls hang or time out while every service reports healthy, and the first suspect is the message bus
RabbitMQ moved to 4.x, which removed classic queue mirroring, and the queue type the OpenStack services use changed underneath them
The cloud runs 2025.1 Epoxy or 2024.1 Caracal, which upstream now lists as Unmaintained, and nobody has written down the upgrade path
The team that built the cloud has shrunk, or the support window of the distribution it runs on is ending
Nobody has written down the order in which the database cluster and the message bus come back after a power event
Deployments made with Kolla-Ansible or OpenStack-Helm have drifted from the configuration kept in Git
Upgrades happen every six months by habit, and nobody has decided whether a SLURP upgrade once a year would do
A good fit if you already run OpenStack in production and need the control plane stabilized, an upgrade planned or senior RabbitMQ and database engineers on call.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy OpenStack.
How it breaks, and the fix
Every OpenStack service talks to the others through RabbitMQ. When one consumer slows, its queue grows. At RabbitMQ's memory limit the broker blocks every publisher, so requests that have nothing to do with the slow consumer start timing out too.
Conductor slows, bus fills
Two API services, one RabbitMQ cluster, three queues, three consumers
Publishers send, consumers keep up, and every queue stays short. Broker memory is well below its limit.
The conductor falls behind, for example while waiting on the database. Its queue grows until RabbitMQ's memory alarm trips and the broker blocks all publishers. Compute and agent consumers have nothing to read, and unrelated API requests time out.
The slow consumer is fixed and the conductor queue drains. The memory alarm clears, publishers resume and the other queues fill again.
The message bus is the shared fate of the control plane. The oslo.messaging driver detects dead connections with heartbeats and TCP keepalives, and its documentation now recommends quorum queues, transient quorum queues, a queue manager and stream fanout. RabbitMQ 4.0 removed classic queue mirroring, and RabbitMQ 4.3.0 refuses to create transient, non-durable, non-exclusive queues by default, so the queue settings of a cloud that predates those versions may need changing on upgrade. Kolla-Ansible documents the matching change: all queues became durable in the Epoxy release, with a stop, reconfigure, reset-state and restart procedure to follow first. A review of queue types, memory alarms and consumer lag before the incident is what the control-plane health check delivers.
Our Services
AceMQ runs five OpenStack service lines: a fixed-scope control-plane health check, RabbitMQ for OpenStack, the database and its backups, SLURP upgrade planning, and Kolla-Ansible and OpenStack-Helm operations. Support can follow any of them. AceMQ supports running clouds and builds no new ones.
The fixed-scope entry engagement: a written review of the OpenStack control plane that your own team can act on, with or without AceMQ afterwards.
The message bus every OpenStack service depends on, reviewed and tuned by AceMQ's RabbitMQ engineers.
The database cluster behind the control plane, reviewed for health, backup coverage and the order of a restart.
An upgrade path built on the SLURP rules, covering every release, the RabbitMQ and database steps and the downtime a skip-level upgrade may need.
Running and upgrading deployments made with the community tools, with the configuration kept in version control and reviewed before it is applied.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ OpenStack support gives you an AceMQ engineer and a 15-minute first response when the control plane is failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. AceMQ produces no OpenStack patches: fixes come from OpenStack releases and from your distribution vendor, if you have one.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Release notes and lifecycle dates read against your environment, with an upgrade plan that fits your change windows.
How It Works
An OpenStack engagement at AceMQ runs in four stages: a scoping call with a quote within 1 hour, a control-plane review, a written plan rehearsed on a copy, then changes in your windows and a handover.
Quote within 1 hour
A senior AceMQ engineer asks what you run: OpenStack release, how it was deployed (Kolla-Ansible, OpenStack-Helm or a distribution's tooling), RabbitMQ and database versions, the number of control nodes and what has been failing. A quote request is answered within 1 hour.
Scoped per cloud
RabbitMQ cluster state, queue types, memory and connection behavior, the database cluster and its backups, configuration drift against Git, and release position are read. Findings are ranked by production risk.
Scoped per cloud
Fixes for what the review found, and an upgrade path that names every release and every RabbitMQ and database step, with a rehearsal on a copy and a rollback for each.
Ongoing or fixed scope
Changes are made in your windows with your operators. The work ends with runbooks for the message bus and database and an upgrade calendar. Support can continue 24/7.
A senior engineer, not an SDR. No sales sequence attached.
Planning the upgrade
Every other OpenStack release is a SLURP (Skip Level Upgrade Release Process) release, and upgrades are supported between SLURP releases as well as between adjacent releases. That makes the upgrade a choice of path, and the path decides how many times the message bus and the database are touched.
Where you are
Record the release and whether it is SLURP, the deployment tool, RabbitMQ and database versions, the queue types the services use, backup status and local patches. A release that upstream lists as Unmaintained receives no releases while community interest lasts, and the policy sets no fixed duration.
Where you go
Upgrades between SLURP releases are supported. From a non-SLURP release the only path is the next release, and non-SLURP to non-SLURP is neither tested nor required. Rolling upgrades between SLURP releases are not guaranteed, so plan for downtime, and finish data migrations on the source release before moving on.
The message bus
Kolla-Ansible documents that the default changed to durable queues in the Epoxy release, with a procedure to follow before upgrading: stop the services that use RabbitMQ, reconfigure, reset RabbitMQ state with kolla-ansible rabbitmq-reset-state, then restart so services recreate durable queues. It also limits RabbitMQ upgrades to allowed version paths and fails the version check with a suggested intermediate version when a path is invalid.
Before production
Run the whole path on a copy of the control plane, time the downtime and keep a rollback point for each release. The result is a calendar your operators can run and a runbook for the next SLURP.
Typical engagements
Typical OpenStack engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Infrastructure Team
A typical engagement for a team running OpenStack on its own hardware: a review of the RabbitMQ message bus and the database behind the control plane, and a written SLURP upgrade plan rehearsed on a copy.
RabbitMQ
MariaDBKolla-Ansible
Mid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
Docker
KubernetesSaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
PrometheusSolutions
AceMQ covers OpenStack end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed OpenStack on your infrastructure and fully managed OpenStack on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running OpenStack for you.
Compare the four OpenStack support tiersSide by side
OpenStack ships every six months, and every other release is a SLURP release. A SLURP release can be upgraded to the next SLURP release, and any release to the one after it. Each row below is one release, with its upstream status from releases.openstack.org on 4 November 2026 and the route out of it.
| Release | Upstream status | Supported route out | What to plan |
|---|---|---|---|
| 2026.2 Hibiscus | Maintained, non-SLURP. Released 30 September 2026, with end of life estimated for 26 April 2028. | To the next release, 2027.1 Indri, which is SLURP and estimated for 24 March 2027. | Fits teams that upgrade every six months. Each hop is a RabbitMQ and database checkpoint. |
| 2026.1 Gazpacho | Maintained, SLURP. Released 1 April 2026, with the Unmaintained phase estimated for 27 October 2027. | To the next SLURP release, or release by release. | The release to target for a yearly upgrade cycle. |
| 2025.2 Flamingo | Maintained, non-SLURP. End of life estimated for 28 April 2027. | To the next release, 2026.1 Gazpacho, which is SLURP. A non-SLURP release has no other supported path. | Schedule the hop to Gazpacho before the estimated end of life. |
| 2025.1 Epoxy | Unmaintained, SLURP. No end-of-life date is set. | SLURP to SLURP, directly to 2026.1 Gazpacho. Downtime may be needed. | Kolla-Ansible's durable-queue change landed in this release. Confirm its reset procedure was followed before planning further hops. |
| 2024.2 Dalmatian | End of life since 29 April 2026. Non-SLURP. | Only to the next release, 2025.1 Epoxy. | Two hops: Epoxy first, then Gazpacho. Rehearse each one. |
| 2024.1 Caracal | Unmaintained, SLURP. No end-of-life date is set. | SLURP to SLURP: 2025.1 Epoxy, then 2026.1 Gazpacho. | Two hops. The Epoxy hop carries Kolla-Ansible's queue-durability procedure. |
Unmaintained means upstream publishes no releases while community interest lasts, and the policy sets no fixed duration. AceMQ infers nothing about security fixes from it and produces no OpenStack patches. Distribution vendors publish their own support dates.
One partner, not five
OpenStack rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
AceMQ guidance on RabbitMQ queue types and upgrades, which the OpenStack control plane depends on, plus the services around it: Kubernetes, PostgreSQL and managed services.
FAQs
Five answers on OpenStack from AceMQ: SLURP and skipping releases, why the review starts with RabbitMQ, what AceMQ does not sell, how engagements run and what they cost.
Still have questions about OpenStack? Email an Expert
Every other OpenStack release is a SLURP (Skip Level Upgrade Release Process) release. Upgrades are supported between SLURP releases and between adjacent releases, and non-SLURP to non-SLURP is neither tested nor required. On 4 November 2026 the current release was 2026.2 Hibiscus (non-SLURP) and the current SLURP release was 2026.1 Gazpacho. Skipping a release can need downtime, because rolling upgrades between SLURP releases are not guaranteed.
The OpenStack services use RabbitMQ for messaging, through the oslo.messaging driver, and the database holds the control plane's state, so trouble in either shows up as slow or failing API calls across services. RabbitMQ is AceMQ's core technology. The review starts there because RabbitMQ 4.0 removed classic queue mirroring and oslo.messaging now recommends quorum queues, so the queue type is a live question on many clouds.
No. AceMQ supports clouds that are already running, with OpenStack specialists from its partner network under the AceMQ contract. It builds no new private clouds, and produces no OpenStack patches. AceMQ is an independent provider: it is not a reseller and sells no Red Hat, Canonical, Mirantis or other distribution subscription. OpenStack itself is a project supported by the OpenInfra Foundation.
Yes. AceMQ works on OpenStack in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your OpenStack environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how OpenStack is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer looks at your OpenStack control plane, tells you what to review first, and quotes the work. Quote requests are answered within 1 hour.
Production incident right now?Email an OpenStack Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
