openstack/kolla-ansible.git/ansible/roles/nova-cell, branch stable/2026.1

Fix nova-compute startup after reprovisioning

2026-07-14T20:35:20+00:00

We need to restore the /var/lib/nova/compute_id file to avoid nova-compute failing to start with the following error: nova.exception.InvalidConfiguration: No local node identity found, but this is not our first startup on this host. Refusing to start after potentially having lost that state! K-A now query IDs of hypervisors by their hostname and create necessary compute_id file under node config directory for nova-compute before starting nova-compute containers. The compute_id file gets copied under /var/lib/nova/ on container start up. Co-Authored-By: bjorn lofdahl Co-Authored-By: Seunghun Lee Co-Authored-By: Owen Jones Change-Id: If635577fa240f0953ad02d2c28473480d9ad011d Closes-Bug: #2051011 Signed-off-by: Owen Jones Signed-off-by: Maksim Malchuk (cherry picked from commit 3e4cfd49da38c7db2ac3ad47a75dc89b14cbb513)

Tune libvirtd connection limits for OpenStack

2026-06-29T00:11:47+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

Start virtlogd in nova-libvirt and route console logs to it.

2026-06-25T19:28:28+00:00

Due to implementation choices in qemu and libvirt, standard log rotate does not work on these console files, and instead the usual approach is to have libvirt's virtlogd rotate the contents of the console log file when it gets a bit big. OpenStack Compute knows how to read data from more than one rotated console log file if required to service a REST API request. OpenStack Kolla and Kolla-Ansible deploy OpenStack components in docker or podman containers. An error in the startup configuration for the nova_libvirt container results in the libvirt virtlogd daemon not being run, which results in this console log rotation not occurring. This opens up the risk of a disk usage denial of service attack on a hypervisor. The console log is stored on the same filesystem as ephemeral disks, and OpenStack Nova will take a hypervisor out of service if disk space becomes constrained. There is some protection from the instance console not being able to write data particularly quickly, but it is definitely still possible to fill the hypervisor file system -- especially if multiple instances are used. This misconfiguration appears to exist in all versions of Kolla / Kolla-Ansible as best as I can tell. Flip qemu.conf's stdio_handler from "file" to "logd" so libvirt routes instance console chardevs through virtlogd, which rotates them per /etc/libvirt/virtlogd.conf. Without this, virtlogd runs but is never consulted and console.log grows unbounded. The nova_libvirt command now points at the /usr/local/bin/kolla_nova_libvirt_start helper shipped in the image. Deploying this Kolla-Ansible change against an older image that predates that helper would leave the container unable to start. Add a deploy-time check that inspects the nova_libvirt image for the helper and fails with an explanatory message when it is absent, so an incomplete upgrade (new code, stale image) is caught before the container is reconfigured. Partial-Bug: 2155214 Depends-On: https://review.opendev.org/c/openstack/kolla/+/993065 Change-Id: Ia543939b17cd06714695dff8ef8bd29bc3f8175e (cherry picked from commit 4244e6a91767a4706e59145f6841adbeeac048bb) Signed-off-by: Michael Still

Fix for overly restrictive permissions on ca-certificates directory

2026-05-12T05:56:37+00:00

Closes-Bug: #2112280 Change-Id: I52499bdf2b7fc70f91a4c2920749bfef83a79850 Signed-off-by: Rafal Lewandowski Signed-off-by: Michal Nasiadka (cherry picked from commit e302bab31f30296f7d6f41c3d46e19cf5668b97a)

Merge "nova-compute: Copy multipath.conf into nova-compute container"

2026-04-28T12:05:49+00:00

Support multiple Nova Compute Ironic instances

2026-04-24T13:47:26+00:00

Adds support for deploying multiple instances of the Nova Compute Ironic service on the same host. This is useful in large baremetal deployments, where the sharding and/or conductor group feature is used to scale out the service. A further patch to support deploying multiple Ironic conductor instances will follow. Co-Authored-By: Bartosz Bezak Co-Authored-By: Bertrand Lanson Change-Id: Ibbddfd87e831a3775c3ed66c80b18e5070cedc90 Signed-off-by: Doug Szumski

nova-compute: Copy multipath.conf into nova-compute container

2026-04-23T07:53:30+00:00

When using multipathd - nova-compute errors out with nonexisting /etc/multipath.conf - let's copy it in Closes-Bug: #2100614 Change-Id: I52716276ab58df57180dc5dec9d7ef1c537d7e8d Signed-off-by: Michal Nasiadka

kolla-toolbox: Template clouds.yaml and use it

2026-04-15T12:17:01+00:00

Basically Ansible heuristic obfuscation methods mark auth: that we pass to openstack.* modules as no_log_values and then obfuscates it's values in other runs (which then end up as **** e.g. auth_url, domain_id, domain name, etc) Example return: "domains": [ { "description": "The ******** domain", "id": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER", "is_enabled": true, "links": { "self": "********/v3/domains/********" }, "name": "Default", "options": {}, "tags": [] } This patch adds clouds.yaml to files templated for kolla-toolbox (but without the password) and only uses password from Kolla-Ansible secrets instead of storing that on disk on all of the nodes. Change-Id: I479445563d5b5dc2e45601e936d89def647da841 Signed-off-by: Michal Nasiadka

Add additional SPICE configuration options

2026-04-02T20:05:13+00:00

Recent changes to OpenStack Compute have added a number of new configuration options for SPICE VDI consoles. Additionally, it is not always desirable to enable the HTML5 transcoding proxy for SPICE consoles in Horizon. This patch adds configuration to globals.yml for most of these new options. Specifically: * nova_spice_html5: whether to enable the HTML5 transcoding proxy or not. Defaults to the previous behaviour of enabling the proxy. Notably, nova_spice_require_secure is not exposed here as it implies that qemu is configured to support TLS, and that TLS certificates have been configured in the nova_libvirt container. These changes are large, and are included in a separate patch for clarity. Additionally, OpenStack Compute added these configuration options in 2023.1, and they are exposed as well: * nova_spice_image_compression: "auto_glz" * nova_spice_jpeg_compression: "auto" * nova_spice_zlib_compression: "auto" * nova_spice_playback_compression: true * nova_spice_streaming_mode: "filter" All configuration options and their various values are documented by OpenStack Compute in their documentation. Partial-Bug: #2131793 (spice-direct consoles) Change-Id: I07f6890f1c7c4e543667d3cbd7b3e82bd9ec83e3 Signed-off-by: Michael Still

ansible-lint: Fix fqcn[actions]

2026-03-24T05:36:36+00:00

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