- openstack-discuss - lists.openstack.org

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