December 2025 - openstack-discuss

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

05 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 03 Dec '25

03 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