openstack/kolla-ansible.git/ansible/roles/cinder/templates/cinder.conf.j2, branch stable/2026.1

Register keystoneauth options for [glance] config group

2026-09-01T13:07:55+00:00

Cinder requires service-to-service authentication with Glance to fetch direct image locations (e.g., for RBD CoW cloning). Because keystoneauth parameters were not explicitly registered for the [glance] section, they could not be properly configured and loaded. This lack of authentication led to HTTP 403 Forbidden errors during fetch_image_location, forcing a fallback to slow image downloads. This patch registers the required keystoneauth options in the [glance] group, enabling proper service-to-service communication. Closes-Bug: #2161971 Change-Id: I2cae59b34b1fbd4fa3bf1c5b2da5277ef4712916 Signed-off-by: Piotr Milewski (cherry picked from commit 1056bc652b148bddc5d4cb667c8d3ef26a322aa9)

Switch to pypi version of j2lint and fix linting errors

2025-12-30T16:31:17+00:00

Since ipwrap filter is getting moved another time inside ansible code - let's switch to j2lint that is actively maintained and it's rules will help in readability of jinja2 templates Change-Id: I6762b691b927de31fa1abd83c4c14e87226fe5e2 Signed-off-by: Michal Nasiadka

ansible-lint: Fix yaml[truthy] in cinder role

2025-11-22T06:08:23+00:00

Change-Id: Id3e2e72698ad5c1ee547789524de816f879d142e Signed-off-by: Michal Nasiadka

Replace Redis with Valkey

2025-11-06T16:01:20+00:00

This change replaces Redis with Valkey, which is non-existent on Rocky Linux 10 / CentOS Stream 10 due to licensing issues. Co-Authored-By: Bartosz Bezak Co-Authored-By: Michal Nasiadka Change-Id: Ifcc6ec6e943c20867d969b0bdb0e4cbac53eea1e Signed-off-by: Grzegorz Koper Signed-off-by: Bartosz Bezak Signed-off-by: Michal Nasiadka

Drop VMware support

2025-08-07T14:42:57+00:00

Change-Id: I20a669bf7796285df04723a9110f9c74788600e1 Signed-off-by: Michal Nasiadka

Add TLS support for MariaDB Connections

2025-07-09T11:41:04+00:00

Since Kolla-Ansible now supports TLS for MariaDB, this patch adds support for services that can use this feature. This feature can be used only when ProxySQL is used as LB. Signed-off-by: Michal Arbet Change-Id: I052c763073c5da29cb8e78004a01a22217dde5da

Don't allow quorum queues to be disabled

2025-04-09T14:20:59+00:00

We will be upgrading RabbitMQ to version 4.0 in Epoxy. This will not work without quorum queues being enabled. Change-Id: Ic6ad64bf8c62bbff175e15029eb121814032c40e

Remove om_enable_rabbitmq_high_availability

2025-04-03T08:02:34+00:00

We're going to upgrade RabbitMQ to 4.0, so this option will not longer be supported. Change-Id: Ide75a8c9086798bf4bdf5bc02d4a1be17017884f

rabbitmq: Add support for using stream queues for fanout

2025-04-02T10:59:07+00:00

The global configuration of rabbit_qos_prefetch_count = 1 in oslo.messaging is a deliberate choice that balances compatibility, fairness, and reliability across all OpenStack services. While some services (particularly those using quorum queues) could theoretically benefit from a higher or even unlimited prefetch count for performance reasons, this is not universally safe. Specifically, RabbitMQ stream queues - which are used in certain OpenStack components do not support a prefetch_count of 0. Setting this value to 0 would result in runtime errors or stalls, as the stream protocol requires a positive credit window to function properly. Oslo.messaging enforces this by raising an error if prefetch_count = 0 is set while using stream queues. A value of 1 is the lowest legal and universally compatible setting. It works safely with both stream and quorum queues. It also improves fairness in message distribution across worker processes. In distributed services like Nova, Neutron, or Cinder, this helps avoid uneven load where one worker might prefetch many messages while others remain idle. A low prefetch count ensures that messages are pulled only when the worker is ready, promoting better load balancing and more predictable performance. Although a higher prefetch value could increase throughput in certain scenarios, it comes at the cost of memory usage, risk of overloading specific nodes, and potential starvation of others. Until oslo.messaging supports queue-type-specific or per-service tuning, the value of 1 remains the safest and most predictable option that works well in mixed OpenStack environments. In summary, rabbit_qos_prefetch_count = 1 is not about optimizing raw throughput for any one service, but about ensuring stable, fair, and reliable behavior across all services that rely on oslo.messaging, regardless of the queue type or broker backend used. Change-Id: I541f704bfa2e98068096331afbdb591659cbc40b

Merge "Rabbitmq: enable quorum for transient queues"

2025-03-28T07:44:21+00:00