openstack/kolla-ansible.git/doc/source, branch stable/2025.1

Merge "Update quickstart deployment instructions for RH family distros" into stable/2025.1

2026-10-22T08:36:17+00:00

Remove Disable Getting Started panel Grafana tasks

2026-10-15T12:30:34+00:00

Since Grafana 13.2, the api/user/helpflags/1 endpoint has been removed [1]. This means the "Disable Getting Started panel" deployment task fails with 404 when a custom home dashboard is added. The best alternative I can find is to set default_home_dashboard_path in grafana.ini, which disables the panel anyway [2] [1] https://github.com/grafana/grafana/pull/124916 [2] https://github.com/grafana/grafana/pull/28750 Change-Id: I78b8657b6ca94d81e3becbba9d5a476d9427658f Signed-off-by: Alex Welsh Closes-Bug: #2166048 (cherry picked from commit c8e7b85b2707f762b2560ad8bed9d107a30ff521) Signed-off-by: Bartosz Bezak

Update quickstart deployment instructions for RH family distros

2026-08-27T12:04:55+00:00

Closes-Bug: #2110921 Change-Id: Ic4705f2bc7a77a0820dd2c049447a6169958e724 Signed-off-by: Rafal Lewandowski

Adopt an AI policy

2026-07-14T09:18:44+00:00

From the experience we have made so far, a lot of AI based contributions tend to cause more work rather than they bring benefit. So we caution people to avoid this when possible. The wording of the policy was adapted from the Zuul project [0]. [0] https://review.opendev.org/c/zuul/zuul/+/993998 Co-Authored-By: James E. Blair Signed-off-by: Dr. Jens Harbott Change-Id: I5fcd5bea33c4f4c87b6f6cf0a96514e8d2da3af3 (cherry picked from commit c202c27ba62bd599a1f9d6fcb07cce5234e33361)

Tune libvirtd connection limits for OpenStack

2026-06-29T00:48:45+00:00

The libvirt daemon ships with max_workers=20 and max_client_requests=5. Those defaults suit a multi-tenant host serving many mutually distrustful clients, where the per-client request cap protects the daemon from any single client monopolising it. Under Kolla-Ansible, nova-compute is effectively the sole privileged client of libvirtd, so the cap of 5 concurrent requests per client becomes the binding constraint rather than a safety net. When several instances build at once -- as they do during the tempest run of the upgrade jobs -- nova-compute's concurrent libvirt RPCs (instance defineXML calls plus the resource-tracker periodic) exceed five. Further requests queue, the connection's keepalive responses are starved, and after keepalive_interval (5s) x keepalive_count (5) = 25s libvirtd closes the connection. nova then sees "Cannot recv data: Input/output error" mid-defineXML, the build is rescheduled, and once all hosts are exhausted the instance is left in ERROR. This presents as flaky upgrade-job failures. Example failure, on the voting kolla-ansible-debian-bookworm-upgrade job (stable/2025.2): https://zuul.opendev.org/t/openstack/build/73ff5a97567d4e05b1774170e0f4aada with primary/logs/kolla/libvirt/libvirtd.txt showing libvirt's own recommendation to tune this parameter: warning : Client hit max requests limit 5. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter ... error : connection closed due to keepalive timeout Raise the per-client cap to 20 -- comfortably above the handful of concurrent builds plus periodics seen in practice -- and the worker pool to 50 so that lifting the per-client limit does not starve other connections such as live migration, health checks and periodic tasks. Both values are exposed as variables (libvirt_max_client_requests and libvirt_max_workers) so operators can tune them further. This is not a Kolla-specific workaround -- the stock libvirtd.conf comment warns that setting max_client_requests too low "may cause keepalive timeouts", and since 2022 libvirtd emits the runtime warning quoted above. As Daniel Berrange explained when he added that warning, the keepalive packets "are subject to the 'max_client_requests' limit just like any API calls", so a client that saturates the limit can have its connection dropped: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5NIJPA7SJVY55VSK7RTEDEHKWOZYJKT6/ Red Hat documents the same tuning for libvirt hosts under load in its knowledge base, notably "Too many active clients are dropping the connection" at https://access.redhat.com/solutions/28146. Assisted-By: Claude Opus 4.8 (1M context, medium effort) Partial-Bug: 2158515 Change-Id: I131c3d4d57dc73ca4dd421cc8f28465248c9830e (cherry picked from commit 5acd2f91d22213ef04bd6988a2a0261982b0cf05) Signed-off-by: Michael Still

docs: warn about password resets in ceph RGW doc

2026-06-19T09:26:03+00:00

Keeping this value to true with external RGW as object storage endpoints can cause outages that are annoying to recover from. We should warn operators about this. Change-Id: I37965382bed6b9762782ec3f9ec3103143d738cc Signed-off-by: Bertrand Lanson (cherry picked from commit 8510b763fec5fbfdcd677177809c682eb69e97dc)

Merge "Fix for Prometheus documentation" into stable/2025.1

2026-04-24T10:37:50+00:00

docs: add Rocky Linux 10 migration guide

2026-04-17T13:46:17+00:00

Change-Id: Ief8b52e57c156023bd2b704967c769c77b37687e Signed-off-by: Bartosz Bezak

[stable-2025.1] valkey: Add subcommand for migration from Redis

2026-04-10T15:02:33+00:00

Co-Authored-By: Bartosz Bezak Change-Id: I808a0fc6886036be20a4fcf43991b3bd92a52f23 Signed-off-by: Michal Nasiadka Signed-off-by: Bartosz Bezak

[stable-2025.1] valkey: Add ansible role

2026-04-10T12:47:45+00:00

This is a non-trivial backport of Valkey deployment that is required for migration to Rocky Linux 10 before upgrading to Flamingo/Gazpacho. Additional subcommand and playbook to migrate from Redis to Valkey will be added in a follow-up. Cephadm bits backported from I51823808c4e4ac08ae8f080aacf6a3759589571d Co-Authored-By: Bartosz Bezak Change-Id: I613d471e5f1e6d563d3853761d8432cba60f3c4c Signed-off-by: Michal Nasiadka Signed-off-by: Bartosz Bezak