- openstack-discuss - lists.openstack.org

Feb 19 Digital Sovereignty WG Recording + Next Steps
by Kendall Nelson 20 Feb '26

20 Feb '26

Hello All! Thank you to all those that were able to find the time to attend and participate in this week's meeting! For those that were not able to attend, here is the recording of today's meeting so that you can catch up and stay engaged with these efforts: https://zoom.us/rec/share/a5cXdx6RsWRNuGt8uqyQEgrVDNnIbexDag8NaUEzhcuyiUmTh… *Now, as far as next steps go: * - Soon, Allison and I will send around some samples of stance text for the landing page and we will *NEED* your feedback and opinions to make sure we have everything covered. - If you have a use case that you think would be good to share, please start working on those case studies ASAP! While we don't need them to launch the landing page (which is scheduled for March 20th-ish) the more content we have ready to go early on, the better! - If you are interested in helping with either of the other initial deliverables ( the comparison sheet or the best practices doc), please add your name to those sections of the etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG>. Also, if you have additional resources that would be helpful in crafting either deliverable, add them to the etherpad. Feel free to also get started throwing content in either as well! They will be living documents in draft form for a while, so nothing has to be perfect. Focus on just getting content in and we will polish things up later. When Allison and I send drafts of stances for review, we will also send out the poll for selecting the next meeting time which is slated for the week of March 9th, likely the 10th, 11th or 12th. Whew, that was a lot of information, but we have a lot of work to get done as a group! I am so excited to see this effort through with you all; we are a strong community and we are stronger together, so thank you for sharing your expertise and time with the Digital Sovereignty Working Group. -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 0

[all] POST_FAILURE in openstack-tox-py310
by Takashi Kajinami 20 Feb '26

20 Feb '26

I feel like this week is one of the most exciting week we have had recently :-P We started seeing consistent POST_FAILURE in openstack-tox-py310 (and other jobs using py310). https://github.com/testing-cabal/testtools/issues/569 The issue was caused by testtools and was fixed in testools 2.8.4, but we likely need to rebuild the image used in CI to pull the fixed version. Please avoid mass recheck or merging any new changes now before you check the CI status carefully. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 3

[neutron] Drivers meeting canceled Friday, February 20th
by Brian Haley 20 Feb '26

20 Feb '26

Hello Neutrinos: I am going to cancel tomorrow's Drivers meeting as there are no topics on the agenda. Just a reminder that our open spec list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[kolla-ansible][ironic] Simple setup for baremetal in Flamingo OpenStack
by vincent lee 20 Feb '26

20 Feb '26

Hi all, I am currently experiencing issues while setting up a basic ironic deployment. My environment consists of a controller running Ubuntu 24.04 and a baremetal host with IPMI support but no operating system installed. I am using kolla-ansible for the Flamingo version OpenStack deployment, and all configuration is being managed through the globals.yml file. One of the controller’s network interfaces is configured to provide DHCP and is connected to a physical switch. I have attached an image (Figure 1) illustrating the physical layout of my setup. My controller had the following configuration: { Two interface (eth0 and eth1) eth0: 10.42.0.1 with netmask 24 eth1: No IP assignment } My compute had the following configuration: { 5 interfaces (eth0, eth1, eth2, eth3, IPMI) eth1: No IP assignment and is connected to switch (MAC: 6F:F1:34:E9:01:29) IPMI: 10.42.0.100 connected to switch } In my globals.yml file, I have the following configuration: { openstack_release: "2025.2" # Flamingo kolla_internal_vip_address: "10.42.0.1" docker_configure_for_zun: true containerd_configure_for_zun: true containerd_grpc_gid: 42463 enable_openstack_core: true enable_haproxy: false enable_cinder: false enable_etcd: true enable_fluentd: true enable_ironic: true enable_kuryr: true enable_magnum: true enable_zun: true ironic_dnsmasq_dhcp_ranges: - range: "10.42.0.5,10.42.0.200" ironic_dnsmasq_boot_file: "pxelinux.0" ironic_cleaning_network: "public1" ironic_dnsmasq_default_gateway: "10.42.0.1" ironic_inspector_kernel_cmdline_extras: ['ipa-lldp-timeout=90.0', 'ipa-collect-lldp=1'] } After completing the deployment, I verified that all the required services are running as docker containers. Immediately afterward, I executed the necessary command to generate the admin credentials, which allows me to use the OpenStack client. 1. $pip install python-openstackclient -c https://releases.openstack.org/constraints/upper/master 2. $kolla-ansible post-deploy 3. $/path/to/venv/share/kolla-ansible/init-runonce After running the command, the following baseline was created. 1. Two network (public1 and demo-net), where public is a flat network 2. cirros image file 3. flavors After that, I uploaded a working kernel, initramfs, and ISO image to OpenStack. I verified that these images were functioning correctly by successfully launching an instance. Next, during the node enrollment process, I ran the following command to enroll my baremetal node. 1. $openstack flavor create --ram 32768 --vcpu 16 --disk 120 baremetal 2. $openstack flavor set --property resources:CUSTOM_IRONIC=1 baremetal 3. $openstack flavor set --property resources:VCPU=0 baremetal 4. $openstack flavor set --property resources:MEMORY_MB=0 baremetal 5. $openstack flavor set --property resources:DISK_GB=0 baremetal 6. $openstack baremetal node create --driver ipmi --deploy-interface direct --driver-info ipmi_username=<IPMI_usernmae> --driver-info ipmi_password=<IPMI_password> --driver-info ipmi_address=10.42.0.100 --driver-info deploy_kernel=<kernel uploaded> --driver-info deploy_ramdisk=<initramfs uploaded> --property local_gb=20 --resource-class baremetal --name My_node After enrolling the node as described above, and since I do not have an ironic Inspector setup, I manually created a port for the enrolled node using the MAC address 6F:F1:34:E9:01:29, which corresponds to the LAN interface. At this point, I am unsure how to proceed with booting the desired image onto the bare-metal host. I would greatly appreciate any guidance on the next steps required to deploy the image to the machine. Best, Vincent

1 0

[nova][meeting] Reserving time for bug scrubbing
by René Ribaud 20 Feb '26

20 Feb '26

Hi everyone, First of all, apologies for the lack of regular updates over the past few months. I haven’t managed to find the time and energy recently, but I’m trying to get back to a more regular rhythm. For the next meeting, I’d like us to explicitly reserve 10 to 15 minutes for bug scrubbing and avoid skipping it. To make this possible, I’ll adjust the agenda accordingly so that this time is clearly allocated. For those volunteering for bug scrubbing: if you have questions about specific bugs, please try to prepare them in advance and, if possible, add them to the agenda document under the Bug Scrubbing section. This should help us make that time more efficient and focused upfront. Thanks everyone, and see you at the meeting. Cheers, René

1 0

[all][elections][tc] TC Election Campaigning Kickoff
by Ian Y. Choi 19 Feb '26

19 Feb '26

Developers, The TC Election Campaigning Period has now started[1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms[2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform[2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. [1] https://governance.openstack.org/election/ [2] https://opendev.org/openstack/election/src/branch/master/candidates/2026.2/…

1 0

[watcher][election][ptl] Douglas Viroel PTL candidacy for 2026.2
by Douglas Viroel 19 Feb '26

19 Feb '26

Hi all, I would like to announce my candidacy for Watcher PTL for the 2026.2 (Hibiscus) cycle. I started contributing to OpenStack during the Stein cycle in Manila project where I still assist with patch reviews, depending on the demand. Starting at 2025.1 release, I have been a Watcher contributor and maintainer, working with other contributors to revive the project and tackle many of the existing technical debts. In 2025.2 I started the effort to remove Eventlet from Watcher and in 2026.1, working as tact-sig, have been refactoring our CI, including our stable branches, to properly test patches in both check and gate pipelines. For the 2026.2 cycle, these are some of the priorities that I plan to focus on: Testing and CI/CD Coverage Improvements: * Support the implementation of new integration test in Watcher Dashboard * Expand test coverage for features, datasources, and/or integrations that remain untested in CI (e.g.: Audit Scope feature) * Start the effort on adding functional tests to Watcher * Continue improvements to check/gate pipelines for master and stable branches Scalability and Availability: * Support for osprofiler in Watcher to enable performance analysis at scale * Performance analysis in Action Plan parallelization OpenStack SDK Migration: * Support the migration effort started in 2026.1 to modernize the remaining integrations Eventlet Removal: * Make native threads the default thread mode in 2026.2 * Address performance gaps when running with native threading * Prepare for Eventlet deprecation in 2027.1 Thank you for your consideration. Douglas Viroel IRC: dviroel

1 0

[cinder] festival of reviews friday 2026-02-20
by Brian Rosmaita 19 Feb '26

19 Feb '26

Hello Argonauts, This is a reminder that the twice-monthly Cinder Festival of Reviews will be held at the end of this week on Friday 20 February. who: Everyone! what: The Cinder Festival of Reviews when: Friday 20 February 2026 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

[nova][ci] nova-live-migration-ceph job failing 100%
by melanie witt 18 Feb '26

18 Feb '26

We have another gate blockage going on right now with the nova-live-migration-ceph job which began to fail sometime on 2026-02-12 on the master branch: https://zuul.opendev.org/t/openstack/builds?job_name=nova-live-migration-ce… failing in the post stage with errors: 2026-02-17 15:33:11.163476 | LOOP [run-evacuate-hook : Stop libvirtd on "controller"] 2026-02-17 15:33:14.016935 | controller | changed: "libvirtd.service" 2026-02-17 15:33:14.671190 | controller | changed: "libvirtd.socket" 2026-02-17 15:33:15.286503 | controller | ok: "libvirtd-admin.socket" 2026-02-17 15:33:15.922638 | controller | ok: "libvirtd-ro.socket" 2026-02-17 15:33:19.293538 | controller | changed: "virtlogd.service" 2026-02-17 15:33:19.918949 | controller | changed: "virtlogd-admin.socket" 2026-02-17 15:33:20.541634 | controller | changed: "virtlogd.socket" 2026-02-17 15:33:21.114233 | controller | ERROR: Item: virtlockd.service 2026-02-17 15:33:21.114481 | controller | { 2026-02-17 15:33:21.114549 | controller | "ansible_loop_var": "item", 2026-02-17 15:33:21.114602 | controller | "item": "virtlockd.service", 2026-02-17 15:33:21.114652 | controller | "msg": "Could not find the requested service virtlockd.service: host" 2026-02-17 15:33:21.114702 | controller | } 2026-02-17 15:33:21.673927 | controller | ERROR: Item: virtlockd-admin.socket 2026-02-17 15:33:21.674126 | controller | { 2026-02-17 15:33:21.674189 | controller | "ansible_loop_var": "item", 2026-02-17 15:33:21.674242 | controller | "item": "virtlockd-admin.socket", 2026-02-17 15:33:21.674332 | controller | "msg": "Could not find the requested service virtlockd-admin.socket: host" 2026-02-17 15:33:21.674388 | controller | } 2026-02-17 15:33:22.221836 | controller | ERROR: Item: virtlockd.socket 2026-02-17 15:33:22.222026 | controller | { 2026-02-17 15:33:22.222090 | controller | "ansible_loop_var": "item", 2026-02-17 15:33:22.222188 | controller | "item": "virtlockd.socket", 2026-02-17 15:33:22.222259 | controller | "msg": "Could not find the requested service virtlockd.socket: host" 2026-02-17 15:33:22.222363 | controller | } This might be related to a recent change in openstack/devstack-plugin-ceph that merged on Feb 12: https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/976279 The breakage is being worked on in the following proposed patches: https://review.opendev.org/q/topic:%22nova-livemigration-ceph%22 Please hold your rechecks if your patch has failed CI due to this issue. -melwitt

1 1

[OSSA-2026-002] OpenStack Nova: calls qemu-img without format restrictions for resize (CVE-2026-24708)
by Jeremy Stanley 18 Feb '26

18 Feb '26

========================================================================= OSSA-2026-002: Nova calls qemu-img without format restrictions for resize ========================================================================= :Date: January 17, 2026 :CVE: CVE-2026-24709 Affects ~~~~~~~ - Nova: <30.2.2, >=31.0.0 <31.2.1, >=32.0.0 <32.1.1 Description ~~~~~~~~~~~ Dan Smith from Red Hat reported a vulnerability in nova. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova's flat image backend to call qemu-img without a format restriction resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with use_cow_images=False) are affected. Patches ~~~~~~~ - https://review.opendev.org/977104 (2024.2/dalmatian) - https://review.opendev.org/977103 (2025.1/epoxy) - https://review.opendev.org/977101 (2025.2/flamingo) - https://review.opendev.org/977100 (2026.1/gazpacho) Credits ~~~~~~~ - Dan Smith from Red Hat (CVE-2026-24708) References ~~~~~~~~~~ - https://launchpad.net/bugs/2137507 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-24709 -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 2