September 2025 - openstack-discuss

[neutron] bug deputy report for 2025w38
by Bence Romsics 22 Sep '25

22 Sep '25

Hi Team, We had the following new reports last week. Two of the High bugs are unassigned at the moment. High: * https://bugs.launchpad.net/neutron/+bug/2124252 [L3] A router with multiple GW ports fails when deleting the first one fixes proposed by Rodolfo: https://review.opendev.org/q/topic:bug/2124252 * https://bugs.launchpad.net/neutron/+bug/2124254 [L3] A router with multiple GW ports, if the first is deleted, the GW info is empty unassigned * https://bugs.launchpad.net/neutron/+bug/2124269 Can't bind an HA router_gateway port to chassis unassigned, could be related to the migration to HA Chassis Group RFEs: * https://bugs.launchpad.net/neutron/+bug/2123836 [RFE] Set a local TXT record in the DHCP agent/dnsmasq * https://bugs.launchpad.net/neutron/+bug/2124215 [RFE] Implement more graceful handling of dhcp_lease_duration reduction Opinion: * https://bugs.launchpad.net/neutron/+bug/2123848 [ovn-octavia-provider] Octavia LB not reachable with custom firewall appliance According to Froyo this should be discussed with OVN cores first. Invalid: * https://bugs.launchpad.net/neutron/+bug/2124259 [ovn] Direct routing (non NAT) does not work between VLAN and Geneve networks Problematic backport of WIP patches. * https://bugs.launchpad.net/neutron/+bug/2125034 During live-migration nova-conductor report 'No valid host was found' due to duplicated port bindings This looks like a nova bug, so I routed it to them. Cheers, Bence

1 0

[kolla][kolla-ansible] Python dependency handling in custom Ansible module without toolbox
by sarah.kh09＠gmail.com 22 Sep '25

22 Sep '25

Hi everyone, I'm developing a new Ansible module for one of the kolla-ansible roles, and it depends on a Python package that needs to be installed via pip on the target nodes. I understand that Kolla Ansible generally avoids installing Python packages directly on hosts, and prefers handling such dependencies through the kolla_toolbox container. However, in my case: - Deploying a sidecar container isn't feasible within our current architecture - Delegating execution to localhost or kolla_toolbox would introduce complexity that we’d rather avoid Given these considerations, I'm looking for alternative ways to handle this dependency while staying aligned with Kolla's principles of reproducibility and container isolation. Has anyone faced a similar situation or found a clean workaround? Is using kolla-toolbox the only standard and recommended approach in such cases? Thanks a lot for your help and feedback!

2 2

[nova] Nova API call duration increases after upgrading to Caracal
by Chang Xue 22 Sep '25

22 Sep '25

Hello, we recently upgraded from Bobcat to Caracal. After upgrading, an interesting increment of duration of nova api call is observed. It's involved to multiple API calls, e.g. os-query-sets, /v2.1/servers/detail, etc. And it seems to be accumulated, meaning whenever nova-api is restarted, the duration seems to be fairly fast, giving response within like 80, 90 ms. As it keeps running for like up to 10 days, the duration increases to over 500 ms. I noticed that Caracal is using UnifiedLimitsDriver instead of DbQuotaDriver. I tried to change nova.conf to use DbQuotaDriver but it seems not working well with reducing the duration. I understand that calling to Keystone and Placement (and likely other external APIs) could result to longer duration, but pretty confused why it shows up as accumulated. Wondering if anyone else in Openstack community noticed the similar issue, thanks!

6 14

[aodh][ceilometer] how create alarms with prometheus ceilometer backend
by Nguyễn Hữu Khôi 22 Sep '25

22 Sep '25

Hello. I try to set up alarm such as: openstack alarm create --type prometheus --type prometheus --name memory_high_alarm --query 'memory_usage{resource_id="21d0792e-2d01-4df9-958a-d9018d13207f"}' --threshold 10 I use ceilometer with prometheus backend but when it shows: +---------------------------+------------------------------------------------------------------+ | Field | Value | +---------------------------+------------------------------------------------------------------+ | alarm_id | cb7b8d07-0af1-4771-92c8-1a4c2ce4d1d1 | | name | memory_high_alarm | | description | prometheus alarm rule | | enabled | True | | ok_actions | [] | | alarm_actions | [] | | insufficient_data_actions | [] | | repeat_actions | False | | type | prometheus | | time_constraints | [] | | project_id | 31ef81adc8ad406e9e91e3eb8776c959 | | user_id | 2e7a252719434d93ae0d270c8753294d | | timestamp | 2025-09-18T14:10:50.467568 | | state | *insufficient data * | | state_timestamp | 2025-09-18T14:10:50.467568 | | state_reason | Not evaluated yet | | severity | low | | evaluate_timestamp | 2025-09-18T14:10:50.485384 | | comparison_operator | eq | | threshold | 10.0 | | query | memory_usage{resource_id="21d0792e-2d01-4df9-958a-d9018d13207f"} | +---------------------------+------------------------------------------------------------------+ and in aodh logs: 2025-09-18 21:20:02.442 1079 INFO aodh.evaluator [-] initiating evaluation cycle on 1 alarms 2025-09-18 21:20:02.442 1079 WARNING aodh.evaluator [-] Skipping alarm cb7b8d07-0af1-4771-92c8-1a4c2ce4d1d1, unsupported type: prometheus I am using openstack 2025.1 I would like to get some guides on this, Many thanks. Nguyen Huu Khoi

2 6

[aodh]how the evaluation process works
by Nguyễn Hữu Khôi 22 Sep '25

22 Sep '25

Hello, I would like to understand how the evaluation process works. For example, I have this rule: openstack alarm create --name memory_use_test \ --type gnocchi_resources_threshold \ --metric memory.usage \ --threshold 102 \ --comparison-operator gt \ --aggregation-method mean \ --granularity 60 \ --evaluation-periods 3 \ --resource-id dca36039-c603-422c-8366-f6ba4e9539c3 \ --resource-type instance Does this mean that when the alarm-evaluator service is running per a period, it will check the last 3 data points, each aggregated over 60 seconds? Thank you. Regards. Nguyen Huu Khoi

2 2

[ptl][charms][tc] Need a PTL volunteer for OpenStack Charms project team
by Goutham Pacha Ravi 21 Sep '25

21 Sep '25

Hello Stackers, We're missing a Project Team Lead (PTL) for the OpenStack Charms project team for the "2026.1" (Gazpacho) release cycle. If you're interested, please let us know by proposing a PTL appointment (e.g. [1]). Thanks, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/c/openstack/governance/+/943254

2 2

[release] Release countdown for week R-1, Sep 22 - 26
by Elõd Illés 19 Sep '25

19 Sep '25

Development Focus ----------------- We are on the final mile of the 2025.2 "Flamingo" development cycle! Remember that the 2025.2 "Flamingo" final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. September 26th, 2025 is the deadline for final 2025.2 "Flamingo" release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on October 1st, 2025. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2026.1 "Gazpacho" development cycle, including discussing Forum and PTG sessions content, in preparation of OpenInfra Summit Europe (Paris-Saclay, France; October 17th-19th, 2025) and virtual OpenStack PTG (October 27th-31st, 2025). Actions ------- Watch for any translation patches coming through on the stable/2025.2 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2025.2 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2025.2 "Flamingo" release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 OpenStack PTG (virtual): October 27th-31st, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[neutron] VPN service/router stays PENDING_CREATE - 2024.2 Dalmatian
by Shubham Yadav 19 Sep '25

19 Sep '25

Hello OpenStack Community, I'm working with OpenStack VPNaaS (using strongSwan as the backend driver) and have a question about tunnel configuration capabilities. Current Setup: OpenStack VPNaaS with strongSwan driver (StrongSwanDriver) Single VPN Service (gateway) with multiple IPSec Site Connections Each connection targets different remote peers with distinct subnets Configuration Details: VPN Service: Connected to a single router Multiple IPSec Site Connections under the same VPN Service: Connection 1: To MY office (10.10.100.0/24) via peer 68.x.y.34 Connection 2: To Rackspace (172.24.60.0/22) via peer 184.n.p.53 Shared IKE and IPSec policies across connections Local endpoint groups covering multiple subnets (192.168.0.0/24, 10.43.0.0/16) Question: Is it supported/recommended to have multiple IPSec Site Connections under a single VPN Service? I understand this creates multiple tunnels from the same OpenStack router to different remote peers. Current Issue: One of my connections shows "PENDING_CREATE" status while the other is "ACTIVE". I'm trying to determine if this is: A configuration issue on my end A limitation of having multiple tunnels per VPN service A strongSwan-specific behavior in the OpenStack context Specific Questions: Does VPNaaS officially support multiple IPSec connections per VPN Service? Are there any known limitations or best practices when using multiple tunnels? Should each remote site have its own dedicated VPN Service instead? I've checked the documentation but couldn't find clear guidance on multi-tunnel scenarios. Any insights from the community would be greatly appreciated. Environment: OpenStack version: 2024.2 Dalmatian Neutron VPNaaS with strongSwan backend Kubernetes-deployed OpenStack (OpenStack-Helm) Waiting for your reply, Thank you for your time and assistance! Best regards, Shubham

1 0

[all][elections][ptl] 2026.1 Gazpacho: PTL Election Conclusion & Results
by Sławek Kapłoński 19 Sep '25

19 Sep '25

Hi, Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant - Dale Smith (dalees) * Barbican - Mauricio Harley (mharley) * Blazar - Pierre Riteau (priteau) * Cinder - Jon Bernard (jbernard) * Cloudkitty - Rafael Weingartner () * Cyborg - Li Liu () * Designate - Omer Schwartz () * Glance - Cyril Roelandt () * Heat - Takashi Kajinami (tkajinam) * Horizon - Tatiana Ovchinnikova (tmazur) * Keystone - Artem Goncharov (gtema) * Kolla - Michal Nasiadka (mnasiadka) * Magnum - Dale Smith (dalees) * Manila - Carlos Silva (carloss) * Masakari - sam sue () * Mistral - Arnau Morin (amorin) * Neutron - Brian Haley (haleyb) * Nova - Rene Ribaud (Uggla) * Octavia - Michael Johnson (johnsom) * OpenStack Helm - Vladimir Kozhukalov (kozhukalov) * OpenStackAnsible - Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK - Artem Goncharov (gtema) * Puppet OpenStack - Takashi Kajinami (tkajinam) * Quality Assurance - Ghanshyam Maan (gmaan) * Rally - Andrey Kurilin (andreykurilin) * Skyline - Wenxiang Wu (wu_wenxiang) * Storlets - Takashi Kajinami (tkajinam) * Sunbeam - Guillaume Boutry (gboutry) * Swift - Tim Burke (timburke) * Tacker - Yasufumi Ogawa (yasufum) * Telemetry - Matthias Runge (mrunge) * Trove - wu chunyang (wuchunyang) * Zaqar - Hao Wang (wanghao) * Zun - Hongbin Lu () Elections: * Horizon: https://civs1.civs.us/cgi-bin/results.pl?id=E_2cbcfa05fd0ec211 For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Slawek Kaplonski, on behalf of the OpenStack Technical Election Officials

2 1

PTG October 2025 Team List Announcement
by Kendall Nelson 19 Sep '25

19 Sep '25

Hello Everyone! The October 2025 Project Teams List is official! Projects + Teams - OpenInfra Project Teams - Kata Containers - StarlingX - - OpenStack - Services - Blazar - Cinder - CloudKitty - Ironic - Keystone - Kolla - Magnum - Manila - Neutron - Nova - Octavia - OpenStack Horizon - OpenStack-Ansible - Sunbeam - Swift - Telemetry - Other OpenStack Teams - Eventlet Removal - openstack-i18n - Release Management - Technical Committee If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon I will be contacting moderators to sign up for time via the PTGBot[1] once it is configured to accept those reservations. As usual, feel free to let us know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://opendev.org/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: http://ptg.openinfra.org/ <http://ptg.openinfra.o/g>

1 0

[heat][mistral][tc] Status of ply
by Takashi Kajinami 19 Sep '25

19 Sep '25

Hi, As you might know, some of the OpenStack projects, heat and mistral, use yaql to support flexible user input. The yaql library has been tiny and stable, thanks to the ply[1] library which is the python-written implementation of lex and yacc . However, it was declared that no further release of ply is planned[2] and the author now suggests copying it into the project[3]. The old released version has been working so far, but I'm unsure if it could survive through recent drastic changes in python package tooling. Looking at the code, it seems all codes are tagged with BSD 3-clause license[3] though the repository lacks the LICENSE file. I guess that the easiest approach is to import the codes to somewhere within yaql (like yaql._ply) and use the imported codes, with a note explaining these codes are imported from ply. This follows the suggestion by the author, but I'd like to get some guidance from TC to make sure it won't break the whole license expectation. An alternative approach is to implement our own parser, though I'm not too sure if that's feasible at least from my PoV. If we want this approach, then we need actual volunteer for it who will immediately start working on it. If neither of the two options above work, we might end up removing yaql functionality completely from OpenStack. AFAIK the one in heat was added for TripleO which was already retired so the impact may be limited, while for mistral removal could have lager impact. Thank you, Takashi [1] https://github.com/dabeaz/ply [2] https://github.com/dabeaz/ply?tab=readme-ov-file#important-notice---october… [3] https://github.com/dabeaz/ply?tab=readme-ov-file#questions-and-answers [4] https://github.com/dabeaz/ply/blob/master/src/ply/lex.py#L10-L33 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

4 5

[horizon][ptg] Call for 2026.1 PTG Horizon topics
by Tatiana Ovchinnikova 19 Sep '25

19 Sep '25

Hello everyone, I have started to put together the etherpad [1] for the upcoming PTG to collect all Horizon related topics we wanted to discuss. Our usual session slots will stay, and if any other slot is needed, please feel free to suggest! [1] https://etherpad.opendev.org/p/horizon-gazpacho-ptg With kind regards, Tatiana

1 0

[all][elections][tc] 2026.1 Gazpacho Technical Committee Election Results
by Sławek Kapłoński 19 Sep '25

19 Sep '25

Hi, Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Sylvain Bauza (bauzas) Dr. Jens Harbott (frickler) Tony Breeds (tonyb) Doug Goldstein (cardoe) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_6cede1084d4586eb Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Slawek Kaplonski, on behalf of the OpenStack Technical Election Officials

2 1

[openstack-helm] K8s cluster broken after reboot
by Viswanath Ediga 18 Sep '25

18 Sep '25

Hello All, I am trying openstack-helm for the fist time. I could deploy the kubernetes cluster using deploy-env <https://opendev.org/openstack/openstack-helm/src/branch/master/roles/deploy…> role in a multinode test environment. But after the reboot of controlplane node, cluster seems to be brokent Kubectl is giving below error *kubectl get pods -AError from server (Forbidden): pods is forbidden: User "kubernetes-admin" cannot list resource "pods" in API group "" at the cluster scope* Any help is appreciated Regards, Kasi Viswanath

1 0

[neutron] L3 routing using VPP
by Kees Meijs | Nefos 18 Sep '25

18 Sep '25

Hi Stackers, Getting more and more enthusiast about Vector Packet Processor (VPP), I'm curious about real life experience with VPP and L3 routers using Neutron (OVS). Did someone dare to actually do this? Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

2 2

Putting DB/WAL on SSD on
by William Muriithi 17 Sep '25

17 Sep '25

Hello, We want to use ceph as the openstack storage system and we can afford a purely SSD based storage system. So we are planning to just setup meta data on SSD and leave the data on HDD The documentation around this isn't very clear and wonder if someone can explain a bit Here is what the documentation say:- https://docs.ceph.com/en/reef/start/hardware-recommendations DB/WAL (optional) 1x SSD partion per HDD OSD 4-5x HDD OSDs per DB/WAL SATA SSD <= 10 HDD OSDss per DB/WAL NVMe SSD What does this mean? I am sorry to say, but it look a tad ambiguous to me, but suspect its obvious once one have experience. I have 6 8TB disk per system, and I want to use replication so will end up with 18 OSD I am hoping I don't need 18 SSD as we don't even have enough bays If we can add in 2 800GB SSD per hardware, how do we optimally map those 18 DW/WAL to a total of 6 SSD disks? Regards, William

4 6

[all][elections][tc][ptl][horizon] Combined PTL/TC 2026.1 cycle Election Voting Last Days
by Ian Y. Choi 16 Sep '25

16 Sep '25

We are coming down to the last hours for voting in the TC and Horizon elections. Voting ends Sep 17, 2025 23:45 UTC. Search your Gerrit preferred email address[0] for the messages with subjects like... Poll: OpenStack 2026.1 Cycle Technical Committee Election Poll Poll: OpenStack 2026.1 Cycle - Horizon PTL Election Poll That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/ What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * find the ID of at least one commit merged to an official deliverable repo[1] over the current and previous cycles, confirm you are an Open Infrastructure Foundation Individual Member[2], and then email the election officials[3] or get in touch in the #openstack-elections channel on the Freenode IRC network. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org and go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [2] https://www.openstack.org/profile/ [3] https://governance.openstack.org/election/#election-officials

1 0

Live-migration never completes memory copy
by Karl Kloppenborg 16 Sep '25

16 Sep '25

Hi Openstack Teams, We’re attempting to live-migrate instances off of a node, we continuously hit a timeout issue where memory copy doesn’t work: 2025-09-12 08:55:20.116 971204 INFO nova.virt.libvirt.driver [None req-250bc815-3323-4619-aef8-a11fdf92b27a 405874cabc5b4bf3912a5f89d54eb0d1 21eb701c2a1f48b38dab8f34c0a20902 - - default default] [instance: 2f496843-a2c4-48d4-bbdc-149a2ea76f1c] Migration running for 274 secs, memory 100% remaining (bytes processed=281505, remaining=8595255296, total=8604033024); disk 100% remaining (bytes processed=0, remaining=0, total=0). 2025-09-12 08:55:58.807 971204 INFO nova.virt.libvirt.driver [None req-250bc815-3323-4619-aef8-a11fdf92b27a 405874cabc5b4bf3912a5f89d54eb0d1 21eb701c2a1f48b38dab8f34c0a20902 - - default default] [instance: 2f496843-a2c4-48d4-bbdc-149a2ea76f1c] Migration running for 312 secs, memory 100% remaining (bytes processed=281505, remaining=8595255296, total=8604033024); disk 100% remaining (bytes processed=0, remaining=0, total=0). 2025-09-12 08:56:02.468 971204 INFO nova.compute.manager [None req-1f91a8d6-1fa7-47b2-8c3f-70925fb7a219 - - - - - -] [instance: 2f496843-a2c4-48d4-bbdc-149a2ea76f1c] During sync_power_state the instance has a pending task (migrating). Skip. 2025-09-12 08:56:37.985 971204 INFO nova.virt.libvirt.driver [None req-250bc815-3323-4619-aef8-a11fdf92b27a 405874cabc5b4bf3912a5f89d54eb0d1 21eb701c2a1f48b38dab8f34c0a20902 - - default default] [instance: 2f496843-a2c4-48d4-bbdc-149a2ea76f1c] Migration running for 352 secs, memory 100% remaining (bytes processed=281505, remaining=8595255296, total=8604033024); disk 100% remaining (bytes processed=0, remaining=0, total=0). 2025-09-12 08:57:17.377 971204 INFO nova.virt.libvirt.driver [None req-250bc815-3323-4619-aef8-a11fdf92b27a 405874cabc5b4bf3912a5f89d54eb0d1 21eb701c2a1f48b38dab8f34c0a20902 - - default default] [instance: 2f496843-a2c4-48d4-bbdc-149a2ea76f1c] Migration running for 391 secs, memory 100% remaining (bytes processed=281505, remaining=8595255296, total=8604033024); disk 100% remaining (bytes processed=0, remaining=0, total=0). 2025-09-12 08:57:56.877 971204 INFO nova.virt.libvirt.driver [None req-250bc815-3323-4619-aef8-a11fdf92b27a 405874cabc5b4bf3912a5f89d54eb0d1 21eb701c2a1f48b38dab8f34c0a20902 - - default default] [instance: 2f496843-a2c4-48d4-bbdc-149a2ea76f1c] Migration running for 431 secs, memory 100% remaining (bytes processed=281505, remaining=8595255296, total=8604033024); disk 100% remaining (bytes processed=0, remaining=0, total=0). Has anyone got insights for this issue? Your help is greatly appreciated. Thanks, Karl. Karl Kloppenborg Chief Technology Officer m: +61 437 239 565 resetdata.com<https://resetdata.com/> [cid:reset_69557fc2-1d63-4932-b5fd-93bd4f39ca7b.png] ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting For more information on the phasing of these requirements for business please visit; https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…<https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…> This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to contact(a)resetdata.com.au<mailto:contact@resetdata.com.au>

4 8

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-2)
by Goutham Pacha Ravi 15 Sep '25

15 Sep '25

Hello Stackers, We're two weeks away from the date of the coordinated 2025.2 "Flamingo" release [1]. At this time, nearly all deliverables that follow the "cycle-with-rc" release model [2] have shipped their first release candidate. Over the next couple of weeks, OpenStack project teams will be expected to test, find and resolve any release blockers in these deliverables. The ongoing elections to fill four seats on the OpenStack Technical Committee and to elect a PTL for the OpenStack Dashboard ("Horizon") project team will conclude at 23:45 UTC on September 17, 2025 [3]. If you haven't already voted, please do so. There were no new governance proposals that were merged in the past week. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on September 9, 2025 [4]. We discussed project teams that had no PTL candidates in the ongoing renewal exercise: Vitrage, OpenStack Charms, Venus, and Monasca. You are all aware that we began the retirement process for the Monasca team [5] and are actively considering a maintainer request. We expect to make a decision past the 2025.2 "Flamingo" coordinated release. We have had a call for help [6][7][8] advertisement for the other projects and will discuss alternatives if those go unanswered. The TC discussed efforts to increase voter turnout for OpenStack elections by encouraging people to opt in to CIVS emails. A related topic was the reduced electorate, which was suspected to be due to OpenInfra Foundation (OIF) membership renewal requirements. The committee agreed to follow up on this after the elections conclude. We discussed default MySQL/MariaDB charset/collation changes that affect most OpenStack service projects. A few key points were discussed, including the need for a potential community goal to migrate from utf8 (which aliases to utf8mb3) to utf8mb4 due to MariaDB's plan to remove the utf8 alias. The meeting also addressed a known issue with Ironic, which has conflicts with the larger utf8mb4 type due to index size limitations. We decided to gather more data on what each project is currently using to better understand the scope of the problem. Dmitriy Robotyogev (noonedeadpunk) and Seunghun Lee (seunghunlee) volunteered to collect this information and add it to a new Etherpad [9] that will inform next steps. After the meeting, Jonathan Wright (JonathanWright[m]) from AlmaLinux joined us to discuss the potential for adding AlmaLinux to OpenStack's supported runtimes, noting its benefits like support for older CPUs (AlmaLinux 10 continues to support older CPUs like x86-64-v2) and more stable CI mirrors compared to CentOS Stream. This could be a significant benefit for OpenStack's CI (Continuous Integration) providers, as it would allow them to utilize their existing, aging hardware more effectively for testing. Community contributors from AlmaLinux want to improve its integration with OpenStack, including creating tailored cloud images for CI and contributing infrastructure resources. We agreed that a clear goal is to establish a working relationship with AlmaLinux volunteers to create and maintain CI images. This effort would likely involve a "pop-up team" to handle the initial implementation, with a long-term plan for AlmaLinux contributors to take ownership of the testing infrastructure. The primary objective is ensuring OpenStack services and deployments can be reliably tested and deployed on AlmaLinux, thereby expanding the project's supported user base. If you're interested to be a part of this effort, please chime in on the #openstack-tc channel on OFTC. The next meeting of the OpenStack Technical Committee is on Tuesday, September 16, 2025, at 1700 UTC. It will be hosted on the #openstack-tc IRC channel on OFTC. Please find the meeting's agenda on the OpenStack wiki [10]. I hope you'll be able to join us there. === Governance Proposals === ==== Open For Review ==== - Retire metalsmith project from bare metal program | https://review.opendev.org/c/openstack/governance/+/958297 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Extend Monasca's inactive state | https://review.opendev.org/c/openstack/governance/+/959392 === Upcoming Events === - 2025-09-17: OpenStack TC and Horizon project elections conclude: https://governance.openstack.org/election/ - 2025-10-01: OpenStack 2026.1 "Flamingo" release day - 2025-10-03: OpenStack's Birthday Meetup, Austin: https://www.meetup.com/openinfra-austin/events/310508680 - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ - 2025-10-27: OpenInfra PTG: https://openinfra.org/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] "cycle-with-rc" release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc [3] OpenStack Elections: https://governance.openstack.org/election/ [4] TC Meeting IRC Log, Sep 9, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-09-17.00.html [5] Retire Monasca project: https://review.opendev.org/c/openstack/governance/+/953671 [6] PTL needed for OpenStack Vitrage: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] PTL needed for OpenStack Charms: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] PTL needed for OpenStack Venus: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [9] Dealing with Mariadb/Mysql changes: https://etherpad.opendev.org/p/gazpacho-collations-charsets [10] TC Meeting Agenda, Sep 16, 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] Bug deputy report for week of September 8th
by Brian Haley 15 Sep '25

15 Sep '25

Hi, I was the Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2122483 - [FT][OVN] ``TestOvn*Sync*`` test failing due to missing IDL lock - https://review.opendev.org/c/openstack/neutron/+/960384 * https://bugs.launchpad.net/neutron/+bug/2122429 - [logapi] ``_check_port_bound_sg`` called outside a READER context - https://review.opendev.org/c/openstack/neutron/+/960271 * https://bugs.launchpad.net/neutron/+bug/2122505 - [OVN][FT] The "Chassis_Private" register contains not expected values in the metadata tests - https://review.opendev.org/c/openstack/neutron/+/960369 * https://bugs.launchpad.net/neutron/+bug/2122524 - [FT] Random fails with ``test_ovs_bridge_name_not_set_if_integration_bridge_not_set`` - Needs owner * https://bugs.launchpad.net/neutron/+bug/2122525 - [FT] Test ``test_create_floatingip_port_forwarding_and_remove_subnets`` randomly failing - Needs owner * https://bugs.launchpad.net/neutron/+bug/2122651 - [FT] ``DBConnectionError`` exception during the ``OpportunisticSqlFixture`` cleanup process - https://review.opendev.org/c/openstack/neutron/+/960727 Medium ------ * https://bugs.launchpad.net/neutron/+bug/2122495 - [OVS Firewall] some flows, IPs from allowed_address_pairs, are dropped after neutron-openvswitch-agent service restart due to CT_MARK=0x1 - https://review.opendev.org/c/openstack/neutron/+/960602 * https://bugs.launchpad.net/neutron/+bug/2122606 - neutron-tempest-plugin-designate-scenario job fails to run due to over-restricted irrelevant files - https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/960659 * https://bugs.launchpad.net/neutron/+bug/2122706 - TestOVNNeutronAgentBase functional tests use system ovsdb - https://review.opendev.org/c/openstack/neutron/+/960892 Low --- * None Wishlist -------- * None

1 0

[neutron][taas][taap-as-a-service] moving client to seperate package
by Mohammed Naser 15 Sep '25

15 Sep '25

Hi there, It seems that at the moment, tap-as-a-service package contains both the server and the client components, which means that if you are trying to pull in the CLI components, you end up with Neutron as well, which is quite heavy. Is there a reason behind it that decision or is this something that someone needs to get around doing but no one has? Thanks, Mohammed

2 4

[all] No documentation for the API wsgi entry point of project APIs
by Thomas Goirand 13 Sep '25

13 Sep '25

Hi, As we're supposed to move away from uwsgi's config: wsgi-script=/usr/bin/<something> I'm switching all (-most every) Debian package to: module=<something-else> in the shipped <project>-api-uwsgi.ini file. In some case, that's fine, the release note tells where to find it. However, in a general way, it's documented nowhere but in the release note. In some cases, like for Magnum, the release note only tells that the wsgi-script is deprecated, without even telling to what I should switch. I've double-guessed that it should be: magnum.wsgi.api:application as this is what devstack/lib/magnum is doing. But I'm not sure, and I'll have to check for that fact after my package is built. Someone told me on IRC that I was right, and that this path is probably the "standard" for all projects. One shouldn't have to hunt for this kind of information. Could we agree on a *STANDARD* way to document this in every project? Or at least document somewhere OpenStack wide, that the standard path *must* be: magnum.wsgi.api:application and that distros and operators should expect it? Or is it that I missed the information and that's already documented? If that's the case, where is it? Cheers, Thomas Goirand (zigo)

4 4

[masakari]HACluster Containers Failing
by Thamanna Farhath 13 Sep '25

13 Sep '25

Hi OpenStack Community, I have installed *Masakari* using Kolla-Ansible, and after that I also installed *HACluster*. However, the HACluster containers are failing and keep exiting. Setup: - 3 controller nodes - Multiple compute nodes - Deployment: Kolla-Ansible My questions are: 1. Do I really need Masakari together with HACluster for instance HA? 2. Is there an alternative or recommended way to deploy HACluster with Kolla-Ansible? 3. Has anyone faced the issue where HACluster containers keep exiting after deployment? Any guidance, troubleshooting tips, or experiences would be very helpful Thanks, Thamanna Farhath N Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

2 1

[release] Release countdown for week R-2
by Thierry Carrez 12 Sep '25

12 Sep '25

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for (almost) all the 2025.2 "Flamingo" deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2025.2 branch creation for all deliverables that have not branched yet, using the latest available 2025.2 "Flamingo" release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2025.2 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2025.2 branch before releasing out of the stable/2025.2 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2026.1 "Gazpacho" development, though the focus should still be on finishing up 2025.2 "Flamingo" until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2025.2 "Flamingo" release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2025.2 "Flamingo" version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: September 26th, 2025 (R-1 week) Final 2025.2 "Flamingo" release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 -- Thierry Carrez (ttx)

1 0

[nova] CPU extra flag invalid
by Kees Meijs | Nefos 12 Sep '25

12 Sep '25

Hi list, On a Compute Node we're seeing the following: > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service Traceback > (most recent call last): > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line > 788, in _check_cpu_compatibility > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > self._compare_cpu(cpu, self._get_cpu_info(), None) > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line > 9029, in _compare_cpu > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service raise > exception.InvalidCPUInfo(reason=m % {'ret': ret, 'u': u}) > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > nova.exception.InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have > compatibility. > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service 0 > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service Refer to > http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service During > handling of the above exception, another exception occurred: > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service Traceback > (most recent call last): > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/oslo_service/service.py", line 807, in > run_service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service service.start() > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/nova/service.py", line 159, in start > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > self.manager.init_host() > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 1421, > in init_host > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > self.driver.init_host(host=self.host) > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line > 723, in init_host > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > self._check_cpu_compatibility() > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service File > "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line > 794, in _check_cpu_compatibility > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service raise > exception.InvalidCPUInfo(msg) > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > nova.exception.InvalidCPUInfo: Configured extra flag: ibpb it not > correct, or the host CPU does not support this flag. Please correct > the config and try again. Unacceptable CPU info: CPU doesn't have > compatibility. > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service 0 > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service Refer to > http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult > 2025-09-12 15:10:37.052 735327 ERROR oslo_service.service This is very interesting, since the CPU supports the ibpb flag for sure (i.e. /proc/cpuinfo cleary lists the feature). Manually adding: > <feature policy="require" name="ibpb"/> to the XML definition works and libvirt is happy. Is there some other name or alias for ibpb we should use? Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0