Skip to content

Unreleased

Changes merged to main that are not yet in a tagged release. If you
deploy with understack_ref: HEAD, these apply to your deployment now.

This page is generated from the fragments in changelog.d/. If nothing
is listed below, nothing merged since the last tag needs operator action.

Pending changes

Action required

components/neutron/values.yaml now pins the oslo_messaging_rabbit queue
settings explicitly rather than inheriting the neutron chart's defaults,
completing the move to quorum queues and RabbitMQ 4.x compatibility that
v0.5 flagged as pending:

conf:
  neutron:
    oslo_messaging_rabbit:
      rabbit_ha_queues: false
      rabbit_quorum_queue: true
      rabbit_transient_quorum_queue: true
      rabbit_qos_prefetch_count: 1
      use_queue_manager: true
      rabbit_stream_fanout: true

The chart default is rabbit_quorum_queues (plural), which is not an
oslo.messaging option and so was a silent no-op; neutron was getting quorum
queues only for transient queues and by way of each vhost's
defaultQueueType: quorum. With the real option name set, neutron requests
x-queue-type: quorum explicitly on its RPC and notification queues, and
fanout queues become streams. This also removes the dependency on classic
queue mirroring, which RabbitMQ 4.x drops entirely.

Queue type is immutable, and an explicit incompatible declare is an error
rather than the silent downgrade to classic that the vhost default gave you.
Before syncing, check each RabbitMQ node for queues in the neutron vhost
that predate this change:

kubectl -n openstack exec rabbitmq-server-0 -- \
  rabbitmqctl list_queues -p neutron name type durable auto_delete

Any queue reported as classic will fail to redeclare with
PRECONDITION_FAILED - inequivalent arg 'x-queue-type'. Delete it so it gets
recreated matching the new declare. Reply and fanout queues are transient and
re-declared automatically by the owning service, so deleting them costs a
brief RPC gap, not data loss. A queue with real content needs more care.

Two things to know about the ironic-neutron-agent queues specifically:

  1. ironic-neutron-agent-member-manager* are auto-delete, and quorum queues
    cannot be. networking-baremetal handles this: it only forces
    amqp_auto_delete=true onto its notification transport when
    rabbit_quorum_queue is unset, so those queues become durable
    non-auto-delete quorum queues instead. This requires
    networking-baremetal 2025.1 or newer.

  2. If the agent is already tripping the broker's consumer_timeout --
    PRECONDITION_FAILED - delivery acknowledgement on channel 1 timed out in
    its logs -- fix that before upgrading the broker to 4.x. On 3.13 the
    message is redelivered indefinitely; RabbitMQ 4.0 defaults quorum queues
    to delivery-limit 20, after which the message is dropped or
    dead-lettered. rabbit_qos_prefetch_count: 1 is set here partly for this
    reason: quorum queues do not support global QoS prefetch, and oslo
    defaults to 0, meaning unlimited.