Release Notes: v0.6.x

Operator-facing upgrade notes for the v0.6 series, newest first. See the
Release Notes index for how to read these pages.

Changes that have merged to main but are not yet in a tagged release are on
the Unreleased page.

v0.6.1 — released 2026-10-01

Action required

The RabbitMQ cluster-operator is now v2.21.1 and the messaging-topology-operator is now v1.19.3. Upgrading the cluster-operator rolls the RabbitMQ StatefulSet, so expect the RabbitMQ pods to restart when the rabbitmq-system Application syncs.

messaging-topology-operator v1.19.0 renamed its webhook resources. The serving-cert Certificate and selfsigned-issuer Issuer are replaced by messaging-topology-serving-cert and messaging-topology-selfsigned-issuer, which write to the same webhook-server-cert Secret. Argo CD prunes the old ones only if the current Application owns them. Clusters whose rabbitmq-system resources were first created under a different Application name keep the old pair. The old certificate then keeps serving the webhook for the old Service name, every topology webhook call fails TLS verification, and User, Vhost, Permission and Policy resources stop reconciling.

After the rabbitmq-system Application syncs, check each cluster:

1. Look for the old resources:

   kubectl -n rabbitmq-system get certificate serving-cert
   kubectl -n rabbitmq-system get issuer selfsigned-issuer
   

   If neither exists and messaging-topology-serving-cert is Ready, there is nothing more to do.

2. Delete the old pair:

   kubectl -n rabbitmq-system delete certificate serving-cert
   kubectl -n rabbitmq-system delete issuer selfsigned-issuer
   

3. cert-manager does not reissue messaging-topology-serving-cert on its own after the old pair is gone, so trigger it. With cmctl:

   cmctl renew -n rabbitmq-system messaging-topology-serving-cert
   

   Or without cmctl, set the condition it sets:

   kubectl -n rabbitmq-system patch certificate messaging-topology-serving-cert \
     --subresource status --type merge -p \
     '{"status":{"conditions":[{"type":"Issuing","status":"True","reason":"ManuallyTriggered","message":"Certificate re-issuance manually triggered","lastTransitionTime":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}]}}'
   

4. Confirm the Certificate is Ready and the Secret now covers messaging-topology-webhook-service:

   kubectl -n rabbitmq-system get certificate messaging-topology-serving-cert
   kubectl -n rabbitmq-system get secret webhook-server-cert \
     -o jsonpath='{.metadata.annotations.cert-manager\.io/alt-names}'
   

   Resources that failed while the webhook was broken are retried with backoff, so they can take a few minutes to go Ready.

Both operator images now come from ghcr.io instead of Docker Hub.

The cluster-operator stays on v2.21.x until every environment runs RabbitMQ 4.2.4 or later, because v2.22.0 switches to a startup probe that older RabbitMQ releases do not support. The messaging-topology-operator stays on v1.19.x until the RabbitMQ credential secrets carry the rabbitmq.com/topology-operator: "true" label that v1.20.0 requires.

Changed

All calls to the Undersync service now come from the undersync ML2 mechanism
driver rather than the understack one. The understack driver keeps the
Neutron-side bookkeeping — allocating and releasing dynamic VLAN segments, trunk
subport segments, router uplinks — and no longer talks to Undersync.

No configuration change: both drivers were already required and the entry point
names are unchanged. On the normal path behaviour is preserved, including how
many times Undersync is notified per operation. One error path differs: if
understack fails while releasing a segment, Undersync is now still notified
for that vlan group, where previously the failure skipped the notification.

undersync must remain listed after understack in mechanism_drivers.
That was already the shipped order, and previously mattered only for completing
port binding at level 1; it now also guarantees segment release and trunk
cleanup finish before Undersync reconciles the switch. neutron-server now
refuses to start if the two are listed the other way round.

v0.6.0 — released 2026-09-30

Action required

The nova chart moves from 2026.1.8+a2a343968 to 2026.1.44+89c5a3c84, which
renames nova's database endpoints and switches its RabbitMQ queues to quorum.
Both need an operator step before syncing.

1. Add oslo_db_cell1 next to oslo_db_api in your deploy repo

OpenStack Helm renamed nova's database endpoints to match the cells v2 layout.
The API database endpoint oslo_db_api became oslo_db, and cell1's database
endpoint oslo_db became oslo_db_cell1. oslo_db_cell0 is unchanged.

components/nova/values.yaml pins endpoints.oslo_db.path to /nova_api and
endpoints.oslo_db_cell1.path to /nova, so the connections keep pointing at
the databases you already have and no database is renamed. What it cannot
supply is the password, which lives in your deploy repo. Add the new endpoint
there alongside the old one; do not rename or remove oslo_db_api yet:

$CLUSTER_NAME/secret-openstack.yaml

  oslo_db_api:
    auth:
      nova:
        password: "${NOVA_DB_PASSWORD}"

  oslo_db_cell1:
    auth:
      nova:
        password: "${NOVA_DB_PASSWORD}"

Both entries carry the same NOVA_DB_PASSWORD. The old chart ignores
oslo_db_cell1 and the new chart ignores oslo_db_api, so carrying both is
safe on either side of the bump. The API database now takes its password from
oslo_db.auth.nova, which already holds the same NOVA_DB_PASSWORD.

Roll it out in this order:

1. Add oslo_db_cell1 to every cluster's secret-openstack.yaml and let it
   sync. Nothing changes on clusters still on the old chart.
2. Bump the cluster's understack_ref to this release.
3. Once every cluster is on this release, remove oslo_db_api.

Removing oslo_db_api before step 2 breaks the old chart: its
[api_database] connection falls back to the chart's placeholder password and
the nova API stops working. Skipping step 1 breaks the new chart the same way
for [database]: nova-db-sync cannot reach the cell database, and
nova-manage cell_v2 update_cell rewrites the cell1 mapping from that bad
connection. Neither touches data; adding the missing entry and re-running
nova-db-sync recovers.

To confirm after step 2, check that the two connections in nova.conf still
name nova_api and nova:

kubectl -n openstack get secret nova-etc \
  -o jsonpath='{.data.nova\.conf}' | base64 -d | grep -A1 '^\[\(api_\)\?database\]'

2. Delete classic fanout queues in the nova vhost

The chart now sets rabbit_quorum_queue, rabbit_transient_quorum_queue and
use_queue_manager to true and rabbit_ha_queues to false, the same move
v0.5 made for neutron. Leftover classic fanout queues keep their old
non-durable *_fanout exchanges alive, and those reject the new durable
declare. Delete them; --if-empty --if-unused skips any queue that still has
messages or consumers:

for queue in $(kubectl -n openstack exec rabbitmq-server-0 -c rabbitmq -- \
    rabbitmqctl --no-table-headers list_queues -p nova name type durable auto_delete \
    | grep classic | grep fanout | awk '{ print $1 }'); do
  kubectl -n openstack exec rabbitmq-server-0 -c rabbitmq -- \
    rabbitmqctl delete_queue -p nova "${queue}" --if-empty --if-unused
done

Skipping this breaks nova-compute-ironic without a clear error. It stops as
soon as it starts its compute-alt RPC server, runs its graceful shutdown and
exits 0, so the pod restarts in a loop. On rax-dev-iad3-dev the leftover was
compute-alt_fanout, kept alive by an old classic compute-alt_fanout_<uuid>
queue.

Deprecations and removals

The charts no longer render Ingress resources, nor the Service objects and
TLS secrets that backed them. components/nova/values.yaml drops the
manifests.ingress_*, manifests.service_ingress_* and
network.use_external_ingress_controller toggles, along with the unused
nova-tls-public certificate reference. UnderStack already fronts nova with
its own ingress, so nothing changes in practice.

Nova's [cell0_database] config section is gone; it was never a real Nova
option. The cell0 connection now reaches nova-db-sync as the
DB_CONNECTION_CELL0 environment variable from the nova-db-cell0-user
secret. Argo will prune the nova-db-api-admin, nova-db-api-user and
nova-db-user secrets, which upstream removed as unmounted, and the
TRANSPORT_URL key from the two nova-rabbitmq-* secrets.

Notes

Two nova overrides in components/nova/values.yaml had never taken effect and
are fixed here, so their intended settings apply for the first time:

• conf.DEFAULT is not a chart value, so force_config_drive: true never
  reached nova.conf. It moves under conf.nova.DEFAULT. Nova already
  behaved this way for baremetal, which is why this went unnoticed.
• pod.probes.api is not a chart key either, so the PUC-2007 probe loosening
  was inert. It moves to pod.probes.api-osapi. Upstream independently
  repointed the osapi and metadata liveness probes at the uwsgi stats port
  (1717), which is served by the uwsgi master and so answers even when every
  worker is busy -- the same crash loop that override was written for.

The inert conf.DEFAULT.osapi_compute_workers: 4 is dropped rather than moved.
The osapi pods run under uwsgi, whose worker count is set directly by
conf.nova_api_uwsgi.uwsgi.processes: 8; the chart only derives it from
osapi_compute_workers when processes is unset, and nova does not read the
option under uwsgi.

Nova's logging.conf now routes oslo_messaging and oslo_service warnings
and errors to stdout. The chart points the root logger at a null handler and
only wires up nova and os.brick, so RabbitMQ declare failures and service
launcher errors were previously discarded without a trace. If a deploy repo
overrides conf.logging.loggers.keys, keep both names in its list.