- openstack-discuss - lists.openstack.org

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on December 19, 2025
by Ildiko Vancsa 19 Dec '25

19 Dec '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __December 19th, 2025 at 1300UTC,__ which is this Friday! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. Topics for this call: - As this is the last call of the year, we can utilize it to have a retrospective on the call series and talk about plans for 2026. - We also had a great discussion at the PTG session about how to refactor Ops-related activities, which we can keep exploring for further increased collaboration between related groups: * See Thierry's email for initial details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… * Meeting notes from October 31st: https://etherpad.opendev.org/p/openstack_ops_radiohour If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> <https://matrix.to/#/%23openstack-ops:opendev.org%3Chttps://matrix.to/%23/%2…> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on December 19th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[skyline] possible bug in OIDC usage with skyline
by Taavi Ansper 18 Dec '25

18 Dec '25

Hi We are testing kolla-ansible 2025.2 and we have found a possible bug in skyline. When using OIDC and trying to log in we get an error that looks like this: { "detail": [ { "type": "string_pattern_mismatch", "loc": [ "header", "X-Openstack-Request-Id" ], "msg": "String should match pattern '^req-\\w{8}(-\\w{4}){3}-\\w{12}'", "input": "", "ctx": { "pattern": "^req-\\w{8}(-\\w{4}){3}-\\w{12}" } } ] } Any help or guidance is appreciated :) -- ---- Taavi Ansper taavi.ansper(a)cyber.ee

3 5

#eventlet-removal Thank you for 2025
by Herve Beraud 18 Dec '25

18 Dec '25

Two years ago, we collectively acknowledged that we were facing a demanding and somewhat paradoxical challenge: engaging a significant amount of time and resources to move away from a problematic technology, eventlet, without the promise of immediate functional gains. At that time, this effort could easily have been perceived as a necessary but uncomfortable burden — work that does not ship new features, does not directly address new user requests, and yet requires deep focus, coordination, and perseverance. We deliberately chose not to ignore the problem, not to postpone it, and not to settle for half-measures. Today, as we are reaching the end of 2025, we can clearly state that this choice was the right one. This year has been particularly intense, productive, and revealing of what a committed open source community can achieve when it aligns behind a long-term objective. The migration effort has reached a decisive milestone: more than 61% of the impacted OpenStack deliverables have now shown significant progress. Twenty deliverables are fully migrated, while forty others are actively undergoing migration. More than 424 Gerrit patches proposed this year alone directly contribute to this collective effort. Beyond the numbers, 2025 has delivered concrete, structural results. Several major projects — including Ironic, Heat, Barbican, Mistral, and others — are now fully migrated. Eventlet itself has evolved, gaining support for recent Python versions (3.12, 3.13, 3.14), ensuring compatibility with modern OpenStack runtimes during the transition phase. Oslo.service introduced a new threading backend, offering a fully threading-based execution model. Cotyledon is actively progressing toward supporting new spawning methods. Neutron is now just one step away from completing its migration, Nova can run specific services in threading mode, and teams such as Cinder, Designate, Watcher, Cyborg, and many others have shown sustained and visible momentum. What we are witnessing is more than a migration. It is a collective act of responsibility. Just like the Python 2 to Python 3 transition, this effort is about securing the future, reducing systemic risk, simplifying maintenance, and restoring long-term innovation capacity. It is about choosing durability over comfort, clarity over accumulation, and sustainability over short-term convenience. The foundations we are laying today are already making OpenStack more robust, more predictable, and better prepared for what comes next. As we close this year, I want to express my sincere respect and gratitude to everyone involved. Maintainers, contributors, reviewers, operators, companies — your engagement, patience, and persistence have made this progress possible. The level of coordination and trust demonstrated throughout 2025 is a strong signal, not only for our community, but for the entire industry that relies on OpenStack. On behalf of this community initiative, thank you for your commitment throughout this year. You have proven, once again, that necessary work — even when it does not immediately shine — is often the work that matters the most. I wish you all restful holidays and precious time with your loved ones. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

2 1

[ops][publiccloud-sig] no Public Cloud SIG meeting d.d. 31 December
by Kees Meijs | Nefos 17 Dec '25

17 Dec '25

Hello Stackers, The bi-weekly Public Cloud SIG meeting scheduled on 31 December will be cancelled due to the holiday season. See you next year, and enjoy your time off! 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

[horizon] Cancelling weekly meetings on Dec 24 and Dec 31
by Tatiana Ovchinnikova 17 Dec '25

17 Dec '25

Hello team, SInce the holiday season is starting, I am cancelling the next two IRC weekly meetings on December 24 and December 31. See you all on January 7, 2026. Happy holidays! With kind regards, Tatiana

1 0

[neutron] CI, Team and Drivers meetings canceled next two weeks
by Brian Haley 17 Dec '25

17 Dec '25

Hello Neutrinos: As mentioned at our weekly meeting, I am going to cancel the Neutron CI, Team and Drivers meetings for the next two weeks as most of us will be out-of-office the remainder of the year. Next meetings will be week of January 5th. Have a happy holidays! -Brian

1 0

OpenInfra Foundation 2025 Annual Report Now Available
by Allison Price 17 Dec '25

17 Dec '25

Hi everyone, The OpenInfra Foundation 2025 Annual Report is now published. Many of the themes in the report will be familiar to the OpenStack community, but this serves as a snapshot of how your work over the past year fits into the Foundation’s broader progress and direction. From an OpenStack perspective, the report highlights: Continued production adoption and momentum, reflected in the latest User Survey data and two coordinated releases in 2025. OpenStack’s role as a foundation for modern workloads, including AI infrastructure, edge and telco platforms, and sovereign cloud deployments. Ongoing collaboration across projects, showing how OpenStack works alongside Kata Containers, StarlingX, Zuul, Kubernetes, Ceph, and other open infrastructure technologies. Community visibility and events, including OpenInfra Summit Europe and regional activities where OpenStack users and contributors shared real-world experiences. Read the full report here: https://openinfra.org/annual-report/2025 Share with your network: https://www.linkedin.com/posts/openinfra-foundation_today-weve-published-th… Thank you to everyone who contributed code, reviews, docs, testing, operations experience, and community leadership in 2025. The impact captured in this report is a direct result of the OpenStack community’s continued commitment to building and operating open, production-grade cloud infrastructure. Cheers, Allison

1 0

[cinder] festival of reviews friday 2025-12-19
by Brian Rosmaita 17 Dec '25

17 Dec '25

Hello Argonauts, This is a reminder that the pre-holiday edition of the Cinder Festival of Reviews (last one this year!) will be held at the end of this week on Friday 19 December. who: Everyone! what: The Cinder Festival of Reviews when: Friday 19 December 2025 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

[magnum] Next meeting 20th Jan 2026
by Dale Smith 16 Dec '25

16 Dec '25

Due to holidays, we are taking a break and the following two meetings (23 Dec and 6 Jan) are cancelled. Meetings will resume on 20th Jan 2026. For more meeting details refer to https://etherpad.opendev.org/p/magnum-weekly-meeting -- DALE SMITH Cloud Engineer Catalyst Cloud <https://catalystcloud.nz> Aotearoa New Zealand's cloud provider e dale(a)catalystcloud.nz w catalystcloud.nz <https://catalystcloud.nz> Follow us on LinkedIn <https://www.linkedin.com/company/catalyst-cloud-limited/> Level 6, Catalyst House, 150 Willis St, Wellington 6011 Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267 <tel:+6444992267>.

1 0

[ironic] Retirement of VirtualPDU
by Jay Faulkner 16 Dec '25

16 Dec '25

Hi all, As it's clear the SNMP code in Ironic will be removed next cycle, and CI has been removed as well, we also will be needing to retire VirtualPDU as well -- either this cycle or next. VirtualPDU was never shipped for production use and only mapped SNMP calls into libvirt power actions for devstack. With these jobs removed, it no longer serves a purpose. Please speak up now if you oppose this retirement. Thanks! -- Jay Faulkner Open Source Developer G-Research OSS

1 0

[qa] Onboarding contributors in QA
by Ghanshyam Maan 16 Dec '25

16 Dec '25

Hello Everyone, As you might know that we need more contributors in QA projects[1], I have started a etherpad to onboard new or current OpenStack contriburtors with all the deatils which includes: - Onboarding steps/information in OpenStack: this is for the new contributors in OpenStack - QA projects list and their documentation link - Current working item and help needed: this list will be evolving over time based on current working item. Currently I have listed the open bugs and moving tempest tests to SRBAC defaults. - https://etherpad.opendev.org/p/qa-onboarding I have four contributors started working on moving tempest testst to SRBAC defaults. If you or someone form your organization is interested, feel free to ping me or add your name in etherpad. [1] https://governance.openstack.org/tc/reference/upstream-investment-opportuni… -gmaan

1 0

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 17 December
by Kees Meijs | Nefos 16 Dec '25

16 Dec '25

Hello Stackers, Tomorrow (that's 17 December) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! 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

[OpenStack Ansible] [Deployment] Depolyment errors
by holywine＠outlook.com 16 Dec '25

16 Dec '25

Hello, Trying to deploy OpenStack on 5 hosts (3 infra, 2 compute). During executing command "openstack-ansible openstack.osa.setup_infrastructure" following errors occurred. Can anybody please provide a clue on what went wrong? Thanks in advance! 2025-12-16 16:21:15,379 p=382940 u=root n=ansible INFO| container_name: "infra1-repo-container-0b24c04d" 2025-12-16 16:21:15,379 p=382940 u=root n=ansible INFO| physical_host: "infra1" 2025-12-16 16:21:15,379 p=382940 u=root n=ansible INFO| Container confirmed 2025-12-16 16:21:15,533 p=382940 u=root n=ansible INFO| Using module file /etc/ansible/ansible_collections/gluster/gluster/plugins/modules/gluster_peer.py 2025-12-16 16:21:15,533 p=382940 u=root n=ansible INFO| Pipelining is enabled. 2025-12-16 16:21:15,533 p=382940 u=root n=ansible INFO| <infra1> ESTABLISH SSH CONNECTION FOR USER: root 2025-12-16 16:21:15,534 p=382940 u=root n=ansible INFO| <infra1> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=300 -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="root"' -o ConnectTimeout=5 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ServerAliveInterval=64 -o ServerAliveCountMax=1024 -o Compression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no -o ForwardAgent=yes -T -o 'ControlPath="/root/.ansible/cp/0fbb4d5943"' infra1 'sudo lxc-attach --clear-env --name infra1-repo-container-0b24c04d -- su - root -c '"'"'/bin/sh -c '"'"'"'"'"'"'"'"'/usr/bin/python3.12 && sleep 0'"'"'"'"'"'"'"'"''"'"'' 2025-12-16 16:21:19,534 p=382940 u=root n=ansible INFO| <infra1> (1, b'\n{"changed": false, "rc": 1, "failed": true, "msg": "peer probe: failed: Probe returned with Transport endpoint is not connected\\n", "invocation": {"module_args": {"nodes": ["infra1-repo-container-0b24c04d", "infra2-repo-container-8419857e", "infra3-repo-container-8432350f"], "state": "present", "force": null}}}\n', b"OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files\r\ndebug1: /etc/ssh/ssh_config line 21: Applying options for *\r\ndebug1: auto-mux: Trying existing master at '/root/.ansible/cp/0fbb4d5943'\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid = 386307\r\ndebug3: mux_client_request_session: session request sent\r\ndebug1: mux_client_request_session: master session id: 2\r\n/tmp/ansible_gluster.gluster.gluster_peer_payload_cd62ayz2/ansible_gluster.gluster.gluster_peer_payload.zip/ansible_collections/gluster/gluster/plugins/modules/gluster_peer.py:173: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.\ndebug3: mux_client_read_packet_timeout: read header failed: Broken pipe\r\ndebug2: Received exit status from master 1\r\n") 2025-12-16 16:21:19,534 p=382940 u=root n=ansible INFO| <infra1> Failed to connect to the host via ssh: OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: auto-mux: Trying existing master at '/root/.ansible/cp/0fbb4d5943' debug2: fd 3 setting O_NONBLOCK debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 0 remote debug3: mux_client_request_session: entering debug3: mux_client_request_alive: entering debug3: mux_client_request_alive: done pid = 386307 debug3: mux_client_request_session: session request sent debug1: mux_client_request_session: master session id: 2 /tmp/ansible_gluster.gluster.gluster_peer_payload_cd62ayz2/ansible_gluster.gluster.gluster_peer_payload.zip/ansible_collections/gluster/gluster/plugins/modules/gluster_peer.py:173: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. debug3: mux_client_read_packet_timeout: read header failed: Broken pipe debug2: Received exit status from master 1 2025-12-16 16:21:19,539 p=382940 u=root n=ansible INFO| fatal: [infra1-repo-container-0b24c04d]: FAILED! => changed: false invocation: module_args: force: null nodes: - infra1-repo-container-0b24c04d - infra2-repo-container-8419857e - infra3-repo-container-8432350f state: present msg: |- peer probe: failed: Probe returned with Transport endpoint is not connected rc: 1 BR, Frank

1 0

[blazar] Extending the payload of a notification, to send the entire lease data
by NITIN GUPTA 16 Dec '25

16 Dec '25

Hello Blazar Team, May I have the following change reviewed, for extending the payload of a notification, to send the entire lease data: *https://review.opendev.org/c/openstack/blazar/+/965448 <https://review.opendev.org/c/openstack/blazar/+/965448>* Looking for your feedback as soon as possible. Best regards. -- NITIN GUPTA

2 9

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

15 Dec '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/2134504 - Wrong neutron:host_id in LSP external_ids after live migration - https://review.opendev.org/c/openstack/neutron/+/970564 Medium ------ * https://bugs.launchpad.net/neutron/+bug/2134387 - The is_default flag cannot be modified for external networks - https://review.opendev.org/c/openstack/neutron/+/970204 * https://bugs.launchpad.net/neutron/+bug/2134703 - [OVN] `update_lrouter_ports_ext_ids_name_prefix` should provide the Neutron DB port in `_gen_router_port_ext_ids` call - https://review.opendev.org/c/openstack/neutron/+/970644 Low --- * None Invalid ------- * https://bugs.launchpad.net/neutron/+bug/2134388 - auto allocate topology fails when there is only a single external network - Could no longer reproduce Wishlist -------- * https://bugs.launchpad.net/neutron/+bug/2134606 - [RFE] Add an API that returns a list of available IPs in a network - Asked for more information based on the change already proposed for network-ip-availabilities additions https://review.opendev.org/c/openstack/neutron/+/965083 - Not sure this is useful, will ask at meeting * https://bugs.launchpad.net/neutron/+bug/2135228 - [RFE] Add support for local sink in tap mirror - Asked Miro to add to future Driver's agenda

1 0

[stable][unmaintained] Move old Unmaintained branches to EOL
by Elõd Illés 15 Dec '25

15 Dec '25

Dear OpenStack Community, A bit more than two years ago the Unmaintained state was formalized [1] to signal towards the community that branches beyond the official maintained phase are not officially supported by the project teams themselves, rather by volunteers with interests to keep these branches open for co-operation and bug fix backports. This requires CI maintenance time to time, as CI jobs, infrastructure, packaging and build tools might also change under these legacy unmaintained branches. My employer, Ericsson, chose to support this process for further co- operation on these legacy branches and we stepped up as maintainer for unmaintained branches back till unmaintained/victoria as a starter, as long as it is feasible. Unfortunately, in the past months the point is reached where multiple gate jobs got broken, CI infrastructure elements (old ubuntu versions, old python versions) went to End of Life, too, and keeping meaningful testing [2] functional, is harder and harder on the oldest unmaintained/* branches [3]. Given these circumstances, I'm officially initiating to move old unmaintained branches to End of Life, starting with Victoria, and up till Yoga. I'll prepare the transition patches next week. Thanks to all, who helped with these old branches for this long. Sincerely, Előd Illés irc: elodilles @ #openstack-release / #openstack-stable / #openstack-unmaintained [1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [2] there were arguments about making it possible to merge patches without tempest or even without any tests, but that is something that we should avoid in my opinion as we cannot be sure that we don't introduce regressions if there were no proper testing and no one would want to consume untested code. [3] ubuntu-bionic node type is removed, py36 based jobs disappeared, tempest jobs started to fail with some test cases and with that, grenade jobs as well, etc.

2 3

[kolla] Cancelling weekly meetings on 24th and 31st of December 2025
by Michał Nasiadka 15 Dec '25

15 Dec '25

Hello Cancelling weekly meetings on 24th and 31st of December for obvious reasons The first meeting in 2026 will be on 7th of January Cheers, Michal

1 0

[freezer] Poll for regular IRC meeting time
by Dmitriy Rabotyagov 15 Dec '25

15 Dec '25

Hi everyone! We have decided to re-initiate a regular IRC meeting for the Freezer project to sync on development and let interested parties to step in and be in the loop of project development. In order to select a suitable time for such meeting for everyone currently interested, I have created a poll, you pay find via the link [1] The poll is open until Monday, December 15. If you are interested in the project and want to take part in meetings - feel free to vote on the timing! I have included as many time periods as possible to ensure we can find a suitable one for everyone. Also please ignore specific dates in the poll - we intend to make a meeting on a weekly basis, so only days of the week do matter there. [1] https://beta.framadate.org/polls/365ef8fa4574a9190ec0

2 2

[docs] Rate limiting (?) on docs.openstack.org causing link checks to break
by Florian Haas 15 Dec '25

15 Dec '25

Hello everyone, here's something of a meta-issue that's been bothering me for a while, and I wonder if we can find a solution or a workaround. Our public documentation at docs.cleura.cloud naturally has cross-references to docs.openstack.org. To make sure that our documentation remains current, the CI/CD build for our docs includes an external link checker.[1] That way, if external documentation paths change or go away, we get notified of a build failure, and this enables us to fix or update our docs. Unfortunately, this results in random and intermittent errors like this: Real URL https://docs.openstack.org/keystone/ Check time 2.759 seconds Size 251B Result Error: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) The Keystone docs URL is just an example; this sort of error happens all across the docs. Of the scores of docs.openstack.org links we check, it's usually just one that breaks, but it's always a different one. Kicking the pipeline and rerunning the same link check often "fixes" things, sometimes it doesn't, sometimes it breaks with a different link. I surmise that this is caused by a rate limit applicable on docs.openstack.org. I would understand why such a rate limit exists, so I am not suggesting to remove it, but right now I'm at my wit's end and I'm close to adding docs.openstack.org to the ignore regex in our linkchecker configuration. But I really don't *want* to do that because I'd quite prefer for our docs to contain good cross-references, and so I'm interested in keeping docs.o.o included in the link liveness check. I'm guessing others have run into this issue. If anyone has solved it in a clever way, I'd be grateful for suggestions. Thanks! Cheers, Florian [1] https://linkchecker.github.io/linkchecker/

2 2

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

14 Dec '25

Hello Stackers, We're fifteen weeks away from the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. We're almost at the end of the calendar year, and many community members are taking a well-deserved break during this holiday season observed around the world. The OpenStack Technical Committee did not merge any significant changes in the past week. There's been some more progress on the cleanup effort we embarked on concerning the Monasca project and the governance-sigs repository. Ian Y Choi (ianychoi) and Slawek Kaplonski (slaweq) have graciously agreed to continue as OpenStack's election officials. They're assisted by Tony Breeds (tonyb) who will be the TC liaison. They've begun working on the combined PTL and TC elections that will be conducted in February. We'll share more details about this as they are finalized. === Weekly Meeting === The last meeting of the OpenStack Technical Committee occurred on December 9th, 2025, over the #openstack-tc IRC channel on OFTC [2]. At the meeting, we resolved pending some governance-website patches and established a plan to update the Technical Vision document [3] through brainstorming on an Etherpad. We also discussed the idea of requesting a deadline extension to propose user survey modifications [4]. The team felt that extending the deadline beyond M-2 will allow for input from project teams. We acknowledged the plan to delete unmaintained branches through Yoga [5], with a consensus leaning toward also dropping Zed. Clarification was sought from the "openstack-unmaintained-core" team regarding the "opt-in" maintenance model for newer branches. We noted that Ceph Tentacle is now being tested with DevStack. Additionally, Michal Nasiadka (mnasiadka) is exploring a fix to get an x86-v3 version of OVS to be installed on AlmaLinux while we pursue a packaging fix with AlmaLinux maintainers. This is a must-have because AlmaLinux provides us a good chance of testing OpenStack with an RPM-based distro across most of our cloud providers that have older hardware. The next meeting of the TC will be on Tuesday, December 16th, 2025, at 0800 UTC. Please note this new APAC-friendly time slot. We're gathering the community's interest in a once-monthly meeting in this time slot. Please participate if you're able to. You can find the meeting's agenda and other details on its wiki page [6]. The TC decided to cancel the meetings previously scheduled for December 23rd, 2025, and December 30th, in observance of the holidays. === Governance Proposals === ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - Alter public cloud SIG chair | https://review.opendev.org/c/openstack/governance/+/969371 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 === Upcoming Events === - 2025-12-16: Twelve Clouds of Christmas: https://www.meetup.com/openinfra-austin/events/312269596 - 2026-01-08: 2026.1 Milestone 2 - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] TC Meeting IRC Log, Dec 9 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-09-17.02.html [3] Vision for OpenStack Clouds: https://governance.openstack.org/tc/reference/technical-vision.html [4] OpenStack 2025 User Survey Feedback: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] Unmaintained branch cleanup: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Dec 16 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Kolla-ansible Openstack deployment failed in nova-compute task
by ldemarco＠sinthera.com 11 Dec '25

11 Dec '25

Hi guys, In my first openstack deploy I facing an error in deployment phase. The bootstrap-servers phase and the prechecks phase working fine but the deploy phase stop to work in nova-compute task deployment with the following error [ERROR]: Task failed: Action failed. Origin: /root/kolla-venv/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml:24:7 22 expected_compute_service_hosts: "{{ virt_compute_service_hosts + ironic_compute_service_hosts }}" 23 block: 24 - name: Waiting for nova-compute services to register themselves looking for the nova-compute docker logs I found this event ERROR MissingRequiredSource: /var/lib/kolla/config_files/ceph.client.cinder.keyring file is not found I would you like to point out that the ceph keyring are created and copied to /etc/koll/config/nova in deployment host and /etc/ceph in all openstack host. Some one could help me for fix the issue ? Regards Luca

4 4

migrate ovs to ovn
by Eduardo Morais 11 Dec '25

11 Dec '25

Hey, good afternoon. My name is Eduardo and I’m new to OpenStack. At my job I have a task to migrate OVS to OVN, and I was able to do that, but I have a small question about a problem I'm facing after restarting my environment. When I restart my testing VM and try again, after the migration I get an error message in the Neutron logs about a duplicate entry. The message says that OVN is trying to insert information into the providerresourceassociations table, but the table already has that information and OpenStack works with it. However, after the restart, OpenStack crashes. To make it work again, I have to manually delete the existing entry so the new one can be inserted, and after doing that the problem does not happen anymore, send now for the correct mail, i think.

2 2

[neutron] Drivers meeting canceled Friday, December 12th
by Brian Haley 10 Dec '25

10 Dec '25

Hello Neutrinos: I am going to cancel Friday's Drivers meeting as I will be out the rest of the week. Just a reminder that our open spec list at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[neutron] Neutron L3 HA Issue: Packet Loss and Route Flapping After Restarting openvswitch-vswitchd on Active Controller
by soheil.bakan＠gmail.com 10 Dec '25

10 Dec '25

Hi OpenStack Community, I am experiencing an issue in a 3-controller HA OpenStack environment related to Neutron L3 HA and Open vSwitch. I would appreciate your guidance or any insights. ### Environment - OpenStack version: 2025.1 - 3 controller nodes with HA setup (kolla-ansible) - Neutron L3 HA enabed - OVS + Keepalived (VRRP) - The router’s VRRP master role is currently on one controller - All controllers share the same external/provider network setup ### Issue Description When I restart the `openvswitch-vswitchd` service on the controller node that currently holds the VRRP Master for an HA router: The following problems occur: 1. ICMP traffic (ping) drops for several minutes. 2. The router’s default route begins to bounce between the other two or three controllers. 3. The VRRP master does not stabilize quickly; it keeps flipping between the remaining controllers. 4. As a result, I see packet loss and routing instability for several seconds. ### What I expect Ideally, when `openvswitch-vswitchd` restarts on the master controller: - VRRP should quickly fail over to one of the standby controllers routers - The default route should converge and remain stable - There should be no (or minimal) packet loss I should also say what when i restart neutron_l3_agent or in some cases openvswitch_db issue goes away ### Additional Information If needed, I can share: - Logs from OVS, neutron-l3-agent Thanks in advance for your support. Please let me know if more information is needed. best regards, soheil

3 2

[octavia] Weekly Octavia IRC meeting cancelled until January 7th
by Michael Johnson 10 Dec '25

10 Dec '25

Hello everyone, With the holiday season occurring in various parts of the world, we decided at today's meeting that we will cancel the weekly IRC meeting until January 7th, 2026. I look forward to chatting with you all in the new year! Michael

1 0

[qa] This week QA office hour is canceled
by Ghanshyam Maan 09 Dec '25

09 Dec '25

Hi All, This week QA office hour is canceled. - https://wiki.openstack.org/wiki/Meetings/QATeamMeeting -gmaan

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-16)
by Goutham Pacha Ravi 08 Dec '25

08 Dec '25

Hello Stackers, We're sixteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Project teams are reviewing design specifications and observing spec freezes to advance designs to the implementation phase. In the past week, the OpenStack Technical Committee didn't merge any new governance updates; however, a few change proposals are undergoing community review. We're looking for volunteers to shadow the election officials as they set up and run the TC and PTL elections for the 2026.2 release cycle. If you're interested, please reach out to me, or drop by the #openstack-election IRC channel on OFTC. === Weekly Meeting === The last meeting of the OpenStack Technical Committee occurred on December 2nd, 2025, in the #openstack-tc IRC channel on OFTC [2]. The TC reviewed several outstanding tasks, one of which was the direction in which the FIPS compliance goal was proceeding. This cross-project goal [3] is being moved back to "proposed" status, seeking feedback regarding testing and a goal champion. The focus of the meeting was a deep dive into the friction surrounding significant changes within the community. The TC acknowledged a growing sentiment that existing governance processes are perceived as "bad bureaucracy," creating a situation where policies suffer from "bit rot." For example, we've long had a PTI for Golang despite a lack of actual use—because contributors feel that attempting to update these rules is futile or destined for rejection. We debated potential remedies, such as reviving the "Ideas" repository [4], but concluded that the root issue lies in some outdated guiding documents and practices. The consensus was that the challenges in making big changes stem from a misalignment between current reality and codified policy, leading to a culture where contributors assume the rules cannot be touched. Consequently, we noted that we'd like to review and rewrite the "Technical Vision" document [5]. Since vision statements are intended to be time-bounded, the current version should be considered obsolete. We hope that refreshing this high-level document will serve as the foundation to subsequently prune outdated policies and demonstrate that the community's norms are not immutable. This discussion will continue in this week's meeting that will be held today, December 9th, 2025, in the #openstack-tc channel on OFTC at 1700 UTC. Please see the agenda on the meeting's wiki page [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - Alter public cloud SIG chair | https://review.opendev.org/c/openstack/governance/+/969371 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 === Upcoming Events === - 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-12-12: Athens OpenStack User Group Meetup: https://meetup.com/athens-openstack-user-group/events/312235216 - 2025-12-16: Twelve Clouds of Christmas: https://www.meetup.com/openinfra-austin/events/312269596 - 2026-01-08: 2026.1 Milestone 2 - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] TC Meeting IRC Log, Dec 2 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-02-17.00.html [3] FIPS Compliance Goal: https://governance.openstack.org/tc/goals/selected/fips.html [4] Ideas for OpenStack: https://governance.openstack.org/ideas/ [5] Vision for OpenStack Clouds: https://governance.openstack.org/tc/reference/technical-vision.html [6] TC Meeting Agenda, Dec 9 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[octavia] compute id for a Octavia pool member
by Max Harmathy 08 Dec '25

08 Dec '25

Hello OpenStack community, I regularly face the following problem: From time to time I get notified about issues with some load-balancers where often the issue lies in connectivity between the health monitor and some of the pool members. Now for investigating the problem I often need to know the ID of the server (compute id) for a certain pool member. I haven't found a straightforward way, since the information the OpenStack client provides for a given pool member (openstack loadbalancer member show ...) doesn't include the compute id. I usually try to find out the IP address of the pool member and then match that against the list of servers. But that process is quite tedious. Is there a better way to do this natively or has someone made a tool for that job? Regards, Max -- Max Harmathy UhuruTec AG Tel +49 151 16 341 719 max.harmathy(a)uhurutec.com https://www.uhurutec.com Industriestraße 4 D-70565 Stuttgart Vorsitzender des Aufsichtsrats: Maximilian Buchberger Vorstand: Matthias Haag, Jan Klippel Registergericht Stuttgart, HRB 785603 USt-IdNr: DE354021144

3 3

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 08 Dec '25

08 Dec '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 14

[Nova] Reminder no upstream meeting this week.
by René Ribaud 08 Dec '25

08 Dec '25

Hello, Just a quick note to remind everyone that there is no meeting scheduled for today. We will resume as usual next week. Best regards, René

1 0

[neutron] Bug deputy report - week of Dec 1st
by Slawek Kaplonski 08 Dec '25

08 Dec '25

Hi, I was bug deputy last week. It was very quiet week with just couple of new bugs opened. Below is summary of those: ### Critical - https://bugs.launchpad.net/neutron/+bug/2133807 - tap-as-a-service py313 jobs timeout - CI issue with py313 job, assigned to Lajos, fix proposed https://review.opendev.org/c/openstack/tap-as-a-service/+/969567 ### High - https://bugs.launchpad.net/neutron/+bug/2133487 - ovs_agent main thread raises ValueError on calling os_ken parser without kwargs - **not assigned**, it was also raised on IRC channel, - https://bugs.launchpad.net/neutron/+bug/2134338 - [OVN] Maintenance LRP prefix adding fails over 'dict' doesn't have 'name' attribute - fix already proposed https://review.opendev.org/c/openstack/neutron/+/970056 ### Medium None ### Low - https://bugs.launchpad.net/neutron/+bug/2133796 - [OVN] The OVN agent config option "[agent]extensions" is not present in the default config file - assigned to Rodolfo, ### RFE - https://bugs.launchpad.net/neutron/+bug/2134096 - [OVN] Add both direction to tap mirror - this seems to be very small RFE but technically speaking it is not a bug but request for new feature, I'm don't think we need to discuss that during the drivers meeting really, please take a look at it and comment there - if we will see that discussion is needed, we can always add it to the drivers meeting agenda later, -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[release] Release countdown for week R-16, Dec 08 - Dec 12
by Elõd Illés 05 Dec '25

05 Dec '25

Development Focus ----------------- The Gazpacho-2 milestone will happen next month, on January 8th, 2026. 2026.1 Gazpacho-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/gazpacho/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/gazpa… You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/gazpacho/schedule.html#g-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Gazpacho-2 Milestone: January 8th, 2026 Előd Illés irc: elodilles @ #openstack-release

1 0

Re: using postgresql in production
by Artem Goncharov 04 Dec '25

04 Dec '25

> > On Fri, 5 Dec 2025, 03:25 Sa Pham, <saphi070(a)gmail.com> wrote: > >> HI Artem, >> >> Could you share why you run Keystone with Postgresql ? >> >> I'm running Keystone with Postgresql as well, because my other >> application is using Postgresql so I don't want to deploy two Database >> servers. >> And it's working well without issue. >> > It is more or less a personal preference after working professionally for >> decades with both databases. Postgres features remind me more other major >> relational databases, while MySQL goes "own way". It's not about certain >> needs of Keystone, this is just a personal preference. >> > > > >> >> >> On Thu, Dec 4, 2025 at 11:10 PM Artem Goncharov < >> artem.goncharov(a)gmail.com> wrote: >> >>> In my local tests I always use postgres for Keystone (as well in the >>> keystone-ng testing) and it works. But I agree we do not have dedicated >>> tests as of now, so some edge cases may be broken >>> >>> On Thu, 4 Dec 2025 at 16:37, Sean Mooney <smooney(a)redhat.com> wrote: >>> >>>> nova does not have tempet/devstack jobs either >>>> however we never officially deprecated or removed support for PostgreSQL >>>> >>>> we still test it in our unit tests to ensure the schema applies and some >>>> other minor test coverage but its also been a few years since there was >>>> any real >>>> end to end testing. >>>> >>>> >>>> >>>> On 04/12/2025 14:36, Julia Kreger wrote: >>>> > Greetings, >>>> > >>>> > Ironic ended up removing CI jobs for postgres back in 2024[0] when >>>> > keystone merged postgres incompatible changes which broke the CI job >>>> > and rendered it impossible to test. Previous to that, I think in 2023 >>>> > or 2022, neutron made some changes but quickly fixed the breaking >>>> > changes once they were highlighted. The linked change has some back >>>> > and forth and the mailing list post[1] which spawned job removal from >>>> > Ironic. Ultimately, while people have expressed interest, that has >>>> > never really materialized into action or engagement to keep postgres >>>> > support in a known working state. Unfortunately slight schema and >>>> > behavior differences between the two database platforms really forces >>>> > the need to perform that level of testing as well, which means one is >>>> > likely to encounter issues if they just try to create and use a >>>> > service's database in postgres at this point. >>>> > >>>> > Hope this has helped. >>>> > >>>> > -Julia >>>> > >>>> > [0]: https://review.opendev.org/c/openstack/ironic/+/931055 >>>> > [1]: >>>> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>>> > >>>> > On Thu, Dec 4, 2025 at 3:32 AM Slawek Kaplonski <skaplons(a)redhat.com> >>>> wrote: >>>> >> Hi, >>>> >> >>>> >> Dnia czwartek, 4 grudnia 2025 11:15:55 czas środkowoeuropejski >>>> standardowy Maksim Malchuk pisze: >>>> >>> Hi Slawek, >>>> >>> >>>> >>> I remember some presentations from the summit years ago but can't >>>> find >>>> >>> them. Do you have any links about this information? Maybe docs or >>>> gerrit >>>> >>> commits? >>>> >> I only got >>>> https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.… >>>> and I remember we have discussed that few cycles back in the Neutron room >>>> during the PTG. I don't remember exactly which PTG it was however >>>> >> >>>> >>> >>>> >>> On Thu, Dec 4, 2025 at 11:49 AM Slawek Kaplonski < >>>> skaplons(a)redhat.com> >>>> >>> wrote: >>>> >>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> Dnia czwartek, 4 grudnia 2025 08:26:17 czas środkowoeuropejski >>>> standardowy >>>> >>>> Jiatong Shen pisze: >>>> >>>>> Hello community, >>>> >>>>> >>>> >>>>> We are analyzing the possibility of using PostgreSQL in >>>> production. The >>>> >>>>> reason behind is that the PostgreSQL community is very open and >>>> growing >>>> >>>>> fast, besides many Chinese companies provide PG compatibility. >>>> >>>>> >>>> >>>>> My question is what are the pros and cons between using PG and >>>> MariaDB. >>>> >>>> Are >>>> >>>>> there any tools available to do online data migration for legacy >>>> >>>>> environments? Any insight is deeply appreciated. Thank you. >>>> >>>>> -- >>>> >>>>> >>>> >>>>> Best Regards, >>>> >>>>> >>>> >>>>> Jiatong Shen >>>> >>>>> >>>> >>>> It may be hard as some time ago at least some projects like e.g. >>>> Neutron >>>> >>>> stopped testing and supporting Postrgesql officially. So you may >>>> expect >>>> >>>> some issues there I believe. >>>> >>>> >>>> >>>> -- >>>> >>>> Slawek Kaplonski >>>> >>>> Principal Software Engineer >>>> >>>> Red Hat >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Regards, >>>> >>> Maksim Malchuk >>>> >>> >>>> >> >>>> >> -- >>>> >> Slawek Kaplonski >>>> >> Principal Software Engineer >>>> >> Red Hat >>>> >>>> >> >> -- >> Sa Pham Dang >> Skype: great_bn >> Phone/Telegram: 0986.849.582 >> >> >> ---- typed from mobile, auto-correct typos assumed ----

1 0

Fwd: using postgresql in production
by Artem Goncharov 04 Dec '25

04 Dec '25

On Fri, 5 Dec 2025, 03:25 Sa Pham, <saphi070(a)gmail.com> wrote: > HI Artem, > > Could you share why you run Keystone with Postgresql ? > > I'm running Keystone with Postgresql as well, because my other application > is using Postgresql so I don't want to deploy two Database servers. > And it's working well without issue. > It is more or less a personal preference after working professionally for decades with both databases. Postgres features remind me more other major relational databases, while MySQL goes "own way". It's not about certain needs of Keystone, this is just a personal preference. > > > On Thu, Dec 4, 2025 at 11:10 PM Artem Goncharov <artem.goncharov(a)gmail.com> > wrote: > >> In my local tests I always use postgres for Keystone (as well in the >> keystone-ng testing) and it works. But I agree we do not have dedicated >> tests as of now, so some edge cases may be broken >> >> On Thu, 4 Dec 2025 at 16:37, Sean Mooney <smooney(a)redhat.com> wrote: >> >>> nova does not have tempet/devstack jobs either >>> however we never officially deprecated or removed support for PostgreSQL >>> >>> we still test it in our unit tests to ensure the schema applies and some >>> other minor test coverage but its also been a few years since there was >>> any real >>> end to end testing. >>> >>> >>> >>> On 04/12/2025 14:36, Julia Kreger wrote: >>> > Greetings, >>> > >>> > Ironic ended up removing CI jobs for postgres back in 2024[0] when >>> > keystone merged postgres incompatible changes which broke the CI job >>> > and rendered it impossible to test. Previous to that, I think in 2023 >>> > or 2022, neutron made some changes but quickly fixed the breaking >>> > changes once they were highlighted. The linked change has some back >>> > and forth and the mailing list post[1] which spawned job removal from >>> > Ironic. Ultimately, while people have expressed interest, that has >>> > never really materialized into action or engagement to keep postgres >>> > support in a known working state. Unfortunately slight schema and >>> > behavior differences between the two database platforms really forces >>> > the need to perform that level of testing as well, which means one is >>> > likely to encounter issues if they just try to create and use a >>> > service's database in postgres at this point. >>> > >>> > Hope this has helped. >>> > >>> > -Julia >>> > >>> > [0]: https://review.opendev.org/c/openstack/ironic/+/931055 >>> > [1]: >>> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>> > >>> > On Thu, Dec 4, 2025 at 3:32 AM Slawek Kaplonski <skaplons(a)redhat.com> >>> wrote: >>> >> Hi, >>> >> >>> >> Dnia czwartek, 4 grudnia 2025 11:15:55 czas środkowoeuropejski >>> standardowy Maksim Malchuk pisze: >>> >>> Hi Slawek, >>> >>> >>> >>> I remember some presentations from the summit years ago but can't >>> find >>> >>> them. Do you have any links about this information? Maybe docs or >>> gerrit >>> >>> commits? >>> >> I only got >>> https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.… >>> and I remember we have discussed that few cycles back in the Neutron room >>> during the PTG. I don't remember exactly which PTG it was however >>> >> >>> >>> >>> >>> On Thu, Dec 4, 2025 at 11:49 AM Slawek Kaplonski < >>> skaplons(a)redhat.com> >>> >>> wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> Dnia czwartek, 4 grudnia 2025 08:26:17 czas środkowoeuropejski >>> standardowy >>> >>>> Jiatong Shen pisze: >>> >>>>> Hello community, >>> >>>>> >>> >>>>> We are analyzing the possibility of using PostgreSQL in >>> production. The >>> >>>>> reason behind is that the PostgreSQL community is very open and >>> growing >>> >>>>> fast, besides many Chinese companies provide PG compatibility. >>> >>>>> >>> >>>>> My question is what are the pros and cons between using PG and >>> MariaDB. >>> >>>> Are >>> >>>>> there any tools available to do online data migration for legacy >>> >>>>> environments? Any insight is deeply appreciated. Thank you. >>> >>>>> -- >>> >>>>> >>> >>>>> Best Regards, >>> >>>>> >>> >>>>> Jiatong Shen >>> >>>>> >>> >>>> It may be hard as some time ago at least some projects like e.g. >>> Neutron >>> >>>> stopped testing and supporting Postrgesql officially. So you may >>> expect >>> >>>> some issues there I believe. >>> >>>> >>> >>>> -- >>> >>>> Slawek Kaplonski >>> >>>> Principal Software Engineer >>> >>>> Red Hat >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Maksim Malchuk >>> >>> >>> >> >>> >> -- >>> >> Slawek Kaplonski >>> >> Principal Software Engineer >>> >> Red Hat >>> >>> > > -- > Sa Pham Dang > Skype: great_bn > Phone/Telegram: 0986.849.582 > > >

1 0

using postgresql in production
by Jiatong Shen 04 Dec '25

04 Dec '25

Hello community, We are analyzing the possibility of using PostgreSQL in production. The reason behind is that the PostgreSQL community is very open and growing fast, besides many Chinese companies provide PG compatibility. My question is what are the pros and cons between using PG and MariaDB. Are there any tools available to do online data migration for legacy environments? Any insight is deeply appreciated. Thank you. -- Best Regards, Jiatong Shen

7 7

[keystone][swift][ops] Is anyone using ec2token/s3token middleware in keystonemiddleware ?
by Takashi Kajinami 04 Dec '25

04 Dec '25

Hi, I was going through the codes in keystonemiddleware recently and I'm wondering if anyone is using the following middlewares maintained there ? - EC2Token - S3Token (Note that this is different from S3Token maintained within swift) I'm asking this question because these likely need to be updated to use authenticated access to keystone APIs due to recent vulnerability fix (s3tokens API and ec2tokens API now requires authentications by default). Technically we can fix these, but we would consider just deprecating these middlewares this cycle and removing them in H, if no one is actually using these. At least these codes have received no meaningful update for some years, and there is an indication of no usage like [1]. [1] https://review.opendev.org/c/openstack/keystonemiddleware/+/926459 This means s3token middleware was broken after identity v2 API removal, until this fix was merged in 2024 . Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 2

[puppet] Retiring puppet-vitrage
by Takashi Kajinami 03 Dec '25

03 Dec '25

Hi, Some of you might be aware of this, but the vitrage project was marked inactive during this cycle[1] due to lack of maintainers. This means that we don't expect we have its 2026.1 release. Because our puppet modules are tightly related to the packages of each OpenStack releases, provided by distributions such as RDO or Ubuntu(or UCA), and now we may not expect that vitrage packages are available in 2026.1 packages of these distributions, I now propose retiring puppet-vitrage, the module to deploy and manage vitrage. Please let me know if you have any concern. If I hear no objection, I'll start the formal retirement process. Thank you, Takashi [1] https://review.opendev.org/c/openstack/governance/+/963227 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

Making updates to SIGs (was: Re: [tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-19))
by Goutham Pacha Ravi 03 Dec '25

03 Dec '25

On Tue, Nov 18, 2025 at 1:48 AM Kees Meijs | Nefos <keesm(a)nefos.com> wrote: > > Hi, > > Could we please mark the Public Cloud SIG as "active" instead of "advisory" and replace Tobias and Huang by me Kees Meijs (keesm(a)nefos.com) please? > > Or, how can I do that myself? Hi there Kees! Thank you for checking; I wanted to bounce my response to the list because others may be in a similar situation of wanting to make Chair or documentation updates to the SIGs docs in the TC repo. Any contributor can propose changes to the SIG docs that are maintained here: https://opendev.org/openstack/governance/src/branch/master/reference/sigs In your case, you'd fix up the "chairs" and "status" for the Public Cloud SIG in https://opendev.org/openstack/governance/src/branch/master/reference/sigs/s… and submit your change through the OpenDev Gerrit. There is a bunch of one-time setup that's documented here: https://docs.openstack.org/contributors/code-and-documentation/quick-start.…. Please feel free to reach out if you have any questions. > > Cheers, > Kees > > On 17/11/2025 23:18, Goutham Pacha Ravi wrote: > > [3] OpenStack Special Interest Groups: > https://governance.openstack.org/tc/reference/sigs/ > >

2 1

[eventlet-removal][Neutron] neutron-dynamic-routing project status
by Rodolfo Alonso Hernandez 02 Dec '25

02 Dec '25

Hello all: Since [1], Neutron removed any dependency of "eventlet", including several auxiliary methods used by other projects, in particular neutron-dynamic-routing. We have been trying to clean-up this project, updating the requirements (removing eventlet, updating os-ken) and refactoring the DR agent classes (similar to what was done in the DHCP or L3 agents). But the DR agent is still failing [2], maybe due to an incorrect implementation in os-ken. However, due to the limited time we have, we cannot investigate it. *This email is a request for assistance in getting the users/developers of that project to remediate the code and remove the eventlet dependency.* This topic and the resolution taken was mentioned in the last Neutron meeting [3]. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/961210 [2]https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/956747 [3] https://meetings.opendev.org/meetings/networking/2025/networking.2025-11-18…

2 1

[publiccloud-sig] Public Cloud SIG meeting d.d. 3 December
by Kees Meijs | Nefos 02 Dec '25

02 Dec '25

Hello Stackers, Tomorrow (that's 3 December) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! 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

[Octavia][Load Balancer][2023.1] Amphora Fails Health Check – “No Route to Host” & Timeout Errors
by Thamanna Farhath 02 Dec '25

02 Dec '25

Hi OpenStack Community, I am currently facing an issue with the Load Balancer (Octavia) service in my OpenStack deployment and would appreciate your guidance or suggestions on how to troubleshoot and resolve it. Environment Details: OpenStack Version: 2023.1 (Antelope) Operating System: Ubuntu 22.04 Octavia Backend: Amphora Network Type: VXLAN Deployment Tool: Kolla Ansible Issue Summary: After creating a Load Balancer, the Amphora instance is successfully launched. However, approximately 18 minutes later, the Load Balancer transitions to an ERROR state. Error Observed: octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id a222527f-8336-4fb1-8e9e-0e3ac6e8d580 to go active timeout. octavia.amphorae.driver_exceptions.exceptions.AmpConnectionRetry: Could not connect to amphora, exception caught: HTTPSConnectionPool(host='192.168.200.247', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError: Failed to establish a new connection: [Errno 113] No route to host) What I’ve Tried: Created a VXLAN-based internal network: openstack subnet create --network octavia-mgmt-net --subnet-range 192.168.200.0/24 octavia-mgmt-subnet openstack router create octavia-router openstack router add subnet octavia-router octavia-mgmt-subnet openstack router set octavia-router --external-gateway <public-network-id> Manually configured OVS interface: ovs-vsctl add-port br-int octavia-mgmt -- set interface octavia-mgmt type=internal ip addr add 192.168.200.1/24 dev octavia-mgmt ip link set octavia-mgmt up Security groups are open (allowing all ingress and egress). Verified OVS bridge setup – interface appears correctly on br-int. Behavior Noticed: Amphora instance gets created but fails to communicate with the controller after a while,so health checks fails. The controller cannot reach the Amphora management IP (192.168.200.x). Logs show heartbeat/connection issues (No route to host, timeouts). Request for Help: I would appreciate any of the following: Suggestions to verify if the management network is properly routed from controller to Amphora. Best practices for setting up the Octavia management network using VXLAN. Troubleshooting steps for verifying health manager connectivity to Amphora. 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."

4 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-17)
by Goutham Pacha Ravi 01 Dec '25

01 Dec '25

Hello Stackers, We're seventeen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. On Thursday this week, we'll be wrapping up releases for "trailing" deliverables concerning the OpenStack 2025.2 "Flamingo" release. In the past week, the OpenStack Technical Committee merged a couple of resolutions [2]. The first of these concerned Special Interest Groups in OpenStack [3]. You're probably aware that we began auditing and cleaning up stale information with respect to SIGs. We captured that work in a resolution to formalize the governance update, as governance of the SIGs has evolved over the past few years and some things needed clarification. The second resolution was about the retroactive steps we've taken to advertise the continued maintenance of os-net-config outside of the OpenStack community. We're glad to see the current maintainers taking the steps highlighted in the resolution, and would like to use these artifacts to inform users of the current state of the project. Finally, we made major progress on the retirement of the Monasca project. All deliverables for the project were marked retired in the past week, and we'll proceed with cleaning up references in our documentation and elsewhere. The TC would welcome the development and maintenance of the Monasca project outside of OpenStack, since we discovered users and their use cases while we were mulling this retirement. Eventually, the decision stemmed from the lack of interest to meet the standards of maintenance and release delivery within the OpenStack community. We are looking for volunteers to serve as election officials [4] for the TC and PTL elections that will be held in the next year. If you're interested in serving, please let me know, or chime in on OFTC's #openstack-election channel. The TC and the community would be grateful for your service! === Weekly Meeting === The last weekly meeting of the OpenStack TC was held on November 25th, 2025 in OFTC's #openstack-tc IRC channel [5]. We discussed the resolution on the os-net-config handover, and no objections were raised against completing the process. We also addressed the concerns regarding our current FIPS compliance goal. Our plan is to return the goal to a "proposed" state while the team redefines testing requirements and identifies resources to commit to the goal. We also discussed the changes needed in our documentation to preserve PTL appointment history even as projects transition between governance models. We noted that the Monasca cleanup was nearing completion with adjustments made to validation scripts to ignore legacy license files. Work continues on removing passlib from global requirements in tangential support of the Post-Quantum Cryptography initiative [6]. We addressed an impasse regarding tracking metrics (using Google Analytics) in OpenStack Manuals [7], deciding to merge pending changes now and treat the removal of tracking code as a separate, subsequent task if necessary. Finally, we discussed the Python Project Testing Interface (PTI) in the context of pytest usage for Horizon plugins [8]. The consensus was that while consistency is important, pytest is acceptable if it supports key requirements like parallel execution and generating standard subunit output, and the PTI documentation may need updates to reflect valid use cases beyond stestr. The next meeting of the OpenStack TC is on Tuesday, December 2nd, 2025 at 1700 UTC. This meeting will be hosted on the #openstack-tc channel on OFTC. Please find the meeting's agenda on its wiki page [9]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Ignore monasca repos for legacy validation | https://review.opendev.org/c/openstack/governance/+/968268 ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 === Upcoming Events === - 2025-12-04: 2025.2 release deadline for "cycle-trailing" projects - 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ - 2026-01-08: 2026.1 Milestone 2 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack TC Resolutions: https://governance.openstack.org/tc/resolutions [3] SIGs in OpenStack: https://governance.openstack.org/tc/reference/sigs/ [4] OpenStack Election Officiating: https://governance.openstack.org/election/#election-officials [5] TC Meeting IRC Log, Nov 25 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-25-17.00.html [6] Supporting PQC in OpenStack: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] Google Analytics in OpenStack Manuals: https://review.opendev.org/c/openstack/openstack-manuals/+/905614 [8] pytest in the PTI: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [9] TC Meeting Agenda, Dec 2 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic] iRMC hardware type deprecation in 2026.1
by Jacob Anders 01 Dec '25

01 Dec '25

Hi All, The iRMC hardware type (for Fujitsu PRIMERGY servers) has been deprecated in the 2026.1 cycle and is scheduled for removal from master in 2026.2. The driver will remain in stable and unmaintained branches to fulfill our support obligation. The iRMC driver has been unmaintained for an extended period. Third Party CI stopped working in 2019 and our attempts to contact the provider and have it resume have been unsuccessful. Without CI coverage we can't be confident the driver works with current Ironic releases. This deprecation affects the iRMC hardware type and all its interfaces (bios, boot, inspect, management, power, raid, and vendor). If you're currently using iRMC in your deployment, now is the time to start planning migration to another hardware type. If the hardware supports it, using Redfish hardware type may be an option. Alternatively, the legacy IPMI driver may be of assistance, however may be limited to basic functionality. If you need help or have concerns about this change, please reach out. If your organization is interested in maintaining this driver going forward (including providing CI), we'd be happy to work with you. The deprecation commit with full details can be found here: https://opendev.org/openstack/ironic/commit/7d050f6ae227beb87bb810148a2a0ae… Best Regards, Jacob Anders on behalf of Ironic Community

1 0

[neutron] Bug deputy Nov 24 - Nov 30
by Elvira Garcia Ruiz 01 Dec '25

01 Dec '25

Hi folks! Here you have the list of bugs reported for Neutron during last week. Critical ---------- - https://bugs.launchpad.net/neutron/+bug/2132355 Due to the eventlet migration work networking-bagpipe unit tests are failing Fix commited by Lajos Katona https://review.opendev.org/c/openstack/networking-bagpipe/+/968303 High ------- - https://bugs.launchpad.net/neutron/+bug/2132348 [DEFAULT] metadata_workers and metadata_backlog are ignored Fix proposed by Takashi Kajinami https://review.opendev.org/c/openstack/neutron/+/968242 - https://bugs.launchpad.net/neutron/+bug/2132982 [OVN] Missing ML2 extension 'qos-bw-minimum-ingress' Fix proposed by ralonsoh https://review.opendev.org/c/openstack/neutron/+/968450 Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2132342 OVN LB / FIP PF does not reply to ARP when VIP is from different subnet than router Unassigned. - https://bugs.launchpad.net/neutron/+bug/2132977 [OVN] Allowed address pair with CIDR doesn't mark ports as "virtual" Fix proposed by Slawek https://review.opendev.org/c/openstack/neutron/+/968812 - https://bugs.launchpad.net/neutron/+bug/2133212 [S-RBAC] Regular user can't never send project_id in request body, even with custom policy rules which allows that Assigned to Slawek Wishlist ---------- - https://bugs.launchpad.net/neutron/+bug/2132382 [RFE] Refactor the SR-IOV agent to use the oslo.service launcher Unassigned Best regards! Elvira

1 0

[nova] migration status update too long
by Nguyễn Hữu Khôi 28 Nov '25

28 Nov '25

Hello. I am working on instance migration. After I complete the migration, when I run *openstack server migration list* to check its status, it still shows as *running*. It takes around *12 minutes* before it updates to *completed * status. My OPS: 2025.1 Thank you. Nguyen Huu Khoi

3 12

[openstack-ansible][rabbitmq] Repository change from ppa1 to deb1 for Ubuntu/Debian
by Dmitriy Rabotyagov 28 Nov '25

28 Nov '25

Hi folks, Recently RabbitMQ has changed a repository URL for RabbitMQ and Erlang packages for Ubuntu and Debian. We were using ppa1.rabbitmq.com for all our stable branches, which used to work nicely until recently. With that being said, all existing users need to update their configuration, to use a new repository. For that: * Download GPG key to your deploy host (the one referenced on https://www.rabbitmq.com/docs/install-debian) curl -1sLf https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73… -o /etc/openstack_deploy/pki/rabbitmq.gpg * Create /etc/openstack_deploy/group_vars/rabbitmq_all.yml with content: rabbitmq_repo_url: https://deb1.rabbitmq.com/rabbitmq-server/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_erlang_repo_url: https://deb1.rabbitmq.com/rabbitmq-erlang/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_gpg_keys: - file: /etc/openstack_deploy/pki/rabbitmq.gpg This should fix all existing deployments, while we are proposing and backporting patches for all maintained branches. So a proper fix is expected with the next bugfix release.

2 2

[barbican] Review Request: Fix rewrap_pkek with SoftHSMv2 and CKM_AES_KEY_WRAP_PAD key wrap mechanism (I965443)
by Kaoru Watanabe 27 Nov '25

27 Nov '25

Hi OpenStack Barbican Community, This is my first time submitting a patch to OpenStack, and I am sending this email to kindly request a review. I have great respect for the work you all do in this community. I submitted a patch to address a critical issue we found. This issue occurs when performing key rewrap (barbican-manage hsm rewrap_pkek) using SoftHSMv2 and the CKM_AES_KEY_WRAP_PAD key wrap mechanism. This specific configuration is essential for our production environment, making this fix highly critical for us. We would be grateful if this patch could be merged. Here are the details: Bug Report: https://bugs.launchpad.net/barbican/+bug/2130214 Gerrit Change: https://review.opendev.org/c/openstack/barbican/+/965443 (I965443) The change has been posted for almost a month now. Could you please take a moment to review change I965443? Your feedback is greatly appreciated as we look to move this forward. Thank you very much for your time and collaboration. Best regards, kaoru

1 0

[barbican] Review Request: Fix rewrap_pkek with SoftHSMv2 and CKM_AES_KEY_WRAP_PAD key wrap mechanism (I965443)
by kaoru watanabe 27 Nov '25

27 Nov '25

Hi Openstack Barbican Community, This is my first time submitting a patch to OpenStack, and I am sending this email to kindly request a review. I have great respect for the work you all do in this community. I submitted a patch to address a critical issue we found when performing key rewrap (barbican-manage hsm rewrap_pkek) using SoftHSMv2 and the CKM_AES_KEY_WRAP_PAD key wrap mechanism. Bug Report: https://bugs.launchpad.net/barbican/+bug/2130214 Gerrit Change: https://review.opendev.org/c/openstack/barbican/+/965443 (I965443) This specific configuration (SoftHSMv2 with CKM_AES_KEY_WRAP_PAD) is essential for our production environment, making this fix highly critical for us. We would be grateful if this patch could be merged. The change has been posted for almost a month now. Could you please take a moment to review change I965443? Your feedback is greatly appreciated as we look to move this forward. Thank you very much for your time and collaboration. Best regards, kaoru

1 0

Arbitrary qemu args in nova-compute
by Nathan Harper 27 Nov '25

27 Nov '25

Prompted by Sean’s comment on a different thread: * nova has a policy of not allowign any use of raw qemu args I’ve seen this come up a number of times, but I don’t recall seeing the justification for this policy. We are looking at a scenario where we (as an operator) want to add some specific additional qemu flags to some VMs, but we’re now having to run a local Nova patch to achieve this (experiments with libvirt-hooks haven’t proven fruitful. I can see why we wouldn’t want users to add arbitrary flags, but an unsupported YMMV option in Nova would be helpful -- Regards, Nathan Harper Principal Engineer – Cloud Development Platform Engineering nathanh(a)graphcore.ai<mailto:nathanh@graphcore.ai> www.graphcore.ai →<http://www.graphcore.ai/> ** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<http://www.graphcore.ai/privacy> ** This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information. If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful. Any personal data/special category personal data herein are processed in accordance with UK data protection legislation. All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company. Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at, 1 Maple Road, Bramhall, Stockport, Cheshire, UK, SK7 2DH. This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.

2 2

[nova][keystone] Machine identities
by Ricardo Cano 27 Nov '25

27 Nov '25

Hey guys, I was wondering if openstack had an equivalent to Azure's managed identities or AWS's IAM roles for ec2 to give vm's the ability to interact with the api. Are there any existing patterns that people are using for this? Thanks!

5 4