May 2025 - openstack-discuss - lists.openstack.org

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

25 May '25

Hello Stackers, We're 18 weeks away from the release date for OpenStack 2025.2 "Flamingo" [1]. Next week is the deadline for "cycle-trailing" [2] projects to tag their 2025.1 "Epoxy" deliverables. Elsewhere, service project teams are busy wrapping up design specifications for features expected to be implemented in this release cycle. A call to action regarding the cross-community goal on "eventlet removal" was made to this mailing list [3]. Please join the #openstack-eventlet-removal channel on OFTC and participate in the effort. Several OpenStack governance changes are currently underway. A major proposal among them is a transition [4] from the Contributor License Agreement (CLA) [5] to the Developer Certificate of Origin [6]. This change will affect every OpenStack contributor. The OpenStack Technical Committee is working with the OpenInfra Foundation and the OpenDev Infrastructure teams to enforce DCO compliance starting 2025-07-01. Please take some time to consider its implications and provide your opinions on the TC resolution [4]. Project maintainers are not expected to reject patches with DCO compliance today. If you spot a "Signed-off-by" in the commit message, there's a good chance reviewers have just looked past this, as it wasn't required so far. It's a good time to review what may be necessary and be prepared for the upcoming change [7]. === Weekly Meeting === The weekly IRC meeting of the OpenStack Technical Committee occurred on 2025-05-20 [8]. An action item regarding relinquishing the "quantum" name on PyPI was discussed. The resolution in this regard was acknowledged by the requester and merged shortly after. The OpenDev infra administrators deleted OpenStack artifacts and handed over the project namespace. The majority of the meeting later focused on the transition from CLA (Contributor License Agreement) to DCO (Developer Certificate of Origin). This move is part of a broader transition into the Linux Foundation, with an effective date of June 1, 2025. The TC needed to reconfirm its desire to move to DCO, preferably within the next two weeks, as the previous resolution on this topic was from 2014. A new resolution confirming the board's recommendation was deemed helpful for community feedback. We discussed many aspects of this transition—a key concern being the smoothness of the transition for contributors. While the technical implementation (Gerrit enforcing Signed-Off-By in commit messages and turning off CLA enforcement) is relatively simple, the human and organizational impact is not trivial. The short timeline for the switchover was a major point of contention, as downstream organizations may need to re-engage legal teams and update internal contribution policies. The possibility of having multiple CLAs active in Gerrit (allowing existing contributors to continue under the old CLA while new contributors use a new CLA for the new entity) was raised as a potential solution to mitigate the immediate impact of the short deadline. However, mixing CLA and DCO enforcement was generally seen as undesirable and hard to implement. Post-meeting, the resolution was proposed [4], and the timeline for implementation has been pushed out by a month to allow the community time to prepare and react accordingly. Please expect more communication regarding this in the next few days. The next meeting of the OpenStack TC is on 2025-05-27 at 1700 UTC. This meeting will be held over IRC on the #openstack-tc channel on OFTC. Please find the agenda and other details on the meeting's wiki page [9]. I hope you'll be able to join us there! === Governance Proposals === ==== Merged ==== - [resolution] Relinquish "quantum" project on PyPI | https://review.opendev.org/c/openstack/governance/+/949783 ==== Open for Review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - [resolution] Replace CLA with DCO for all contributions | https://review.opendev.org/c/openstack/governance/+/950463 - Clarify actions when no elections are required | https://review.opendev.org/c/openstack/governance/+/949431 - Fix outdated info on the tc-guide | https://review.opendev.org/c/openstack/governance/+/950446 === Upcoming Events === - 2025-06-03: 15 ans d'OpenStack - OpenInfra UG, Paris: https://www.meetup.com/openstack-france/events/307492285 - 2025-06-05: OpenStack 15 ans! - OpenInfra UG, Rennes: https://www.meetup.com/openstack-rennes/events/306903998 - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] "cycle-trailing": https://releases.openstack.org/reference/release_models.html#cycle-trailing [3] "eventlet-removal" status: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] TC resolution to replace CLA with DCO for all contributions: https://review.opendev.org/c/openstack/governance/+/950463 [5] OpenStack CLA: https://docs.openstack.org/contributors/common/setup-gerrit.html#individual… [6] Developer Certificate of Origin: https://developercertificate.org/ [7] DCO documentation draft: https://review.opendev.org/c/openstack/contributor-guide/+/950839 [8] TC Meeting IRC Log 2025-05-20: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.log.html [9] TC Meeting Agenda, 2025-05-27: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

#eventlet-removal - Progress & Updates - Flamingo milestone 1
by Herve Beraud 25 May '25

25 May '25

TL;DR: We just passed the milestone 1 of Flamingo and at this point big fishes like Neutron, Nova, Glance, and Mistral demonstrated awesome progress in their migration. Oslo.service's new backend is now usable in real life use cases. Eventlet still suffers from a new version of Python. If you have not yet started your migration yet, then, please consider starting ASAP before the aircraft crash. ## OpenStack Updates Neutron's L3 agent is well on its way to running its WSGI features without using Eventlet and activating the new oslo.service threading backend at runtime. Allowing to decouple a bit more the needs of Eventlet at runtime. Nova scheduler is now able to start in threading mode without requiring any usage of Eventlet at runtime. This was possible by also shifting nova-scheduler to the threading backend of oslo.service. More details are available here https://gibizer.github.io/categories/eventlet/ Activating the new threading backend of oslo.service required devstack adaptation to allow having jobs running this execution mode. https://review.opendev.org/c/openstack/devstack/+/948436. Everybody will be able to benefit from these adaptations. Glance continues its adaptation journey by migrating its functional jobs to reduce its needs of Eventlet and to allow it to run jobs in threading mode. oslo.service's new backend is on the way to be landed soon, and is waiting for additional reviews. https://review.opendev.org/c/openstack/oslo.service/+/945720 ## Eventlet Updates Our CI was failing for almost 2 months, we were able to unlock this failing CI and hence we were able to merge several blocked reviews. Last week Eventlet 0.40.0 was released. This new version provides fixes around OpenSSL 3.5+. The support of Python 3.8 and of PyPy were removed. The Python 3.13 issues are still not solved and require further work. ## Call to Action Flamingo is a crucial series in the realization of global migration of OpenStack. We need your involvement to accelerate the progress of this initiative! If your project is affected by Eventlet, now is the time to start your migration. Teams are invited to read the migration guide available at https://removal.eventlet.org/ and are encouraged to join the #openstack-eventlet-removal IRC channel to get help. You'll benefit quickly from the advantages of running your deliverables without using Eventlet. ## Final Thoughts Postponing the beginning of the migration will put additional pressure related to growing runtime failures of Eventlet. We want to prevent this from happening to you. We are now going straight to milestone 2 meaning that we will soon be in the middle of Flamingo. The migration path is now well cleared by all the previous actions and changes applied into OpenStack. Do not be afraid by the migration and take advantage of the collected experience. Your journey start here https://removal.eventlet.org/ Thanks for reading. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

4 5

[tc][all] Moving from CLA to DCO for OpenInfra Contributions
by Jonathan Bryce 23 May '25

23 May '25

Hi everyone, I wanted to flag a recent message on the Foundation mailing list about the possibility to move OpenInfra projects from using the Contributor License Agreement (CLA) to the Developer Certificate of Origin (DCO) [1]. This change would be part of the broader transition into the Linux Foundation and could take effect starting June 1, 2025. It’s something the Board has supported for newer projects, and now existing projects like OpenStack have the opportunity to make the switch as well. I’m happy to join the TC meeting this week to discuss. Thanks, Jonathan 1. https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th…

8 16

[manila] Manila Bugsquash: Focusing on Reviews
by Carlos Silva 22 May '25

22 May '25

Hello zorillas and interested stackers, Next week, the Manila team will have the first bugsquash of the Flamingo cycle. We have plenty of "In Progress" bugs, so we are planning to focus on reviews for this bugsquash. Vida (vhari) groomed the list for the bugsquash [1]. If there's a change you'd like to have some eyes on over the course of the next week, please add that to the list of changes. We will have a kick-off meeting where we'll get some reviewers to share their tricks while reviewing changes with the whole team. More details to join are available on the ICS [2]. [1] https://etherpad.opendev.org/p/manila-flamingo-m1-bugsquash [2] https://gist.github.com/silvacarloss/5a3d3a548b5a92a5425f88b086855568 Looking forward to it, carloss

1 0

[neutron] Drivers meeting canceled Friday, May 23rd
by Brian Haley 22 May '25

22 May '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as it does not look like we will have quorum. Please add things to the wiki [0] to discuss next week, we currently have one agenda item planned: * Integrate OVN BGP capabilities into Neutron OVN driver https://bugs.launchpad.net/neutron/+bug/2111276 Have a nice weekend! -Brian [0] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

[barbican] Cancel Weekly Meeting
by Mauricio Harley 22 May '25

22 May '25

Hi, guys! We need to cancel the weekly meeting that would happen on Monday the 26th. This is necessary since I'll be on PTO that day. Looking forward to meeting you all on the Monday following: June the 2nd. Best regards, Mauricio

1 0

#eventlet-removal - Announcing the New Threading Backend of oslo.service
by Herve Beraud 22 May '25

22 May '25

I'm happy to announce the new version of oslo.service is out! [1] This new version came out with the new Threading backend [2]. OpenStack Upper constraints are on the way to be upgraded to this new version [3]. You can start using the new threading backend by following the steps below: ``` import oslo_service.backend as service service.init_backend(service.BackendType.THREADING) ``` Ideally this backend selection should be made in your patcher module. Almost all OpenStack services own a household patcher. Neutron and Nova already demonstrated a successful adoption of this new backend on Nova scheduler and Neutron L3 agent: - https://review.opendev.org/c/openstack/neutron/+/938404 - https://review.opendev.org/c/openstack/nova/+/948450/17 Devstack is on the way to be adapted to allow you to set up `SYSTEMD_ENV_VARS`. [4] This will allow passing environment variables from zuul job definitions to systemd service files via the local conf. During the Eventlet removal effort this will allow teams to have separate jobs testing the same service in different concurrency modes. The first use case of this is to implement scenarios like passing variable `OS_NOVA_DISABLE_EVENTLET_PATCHING=true` to nova services that already supports running in native threading mode instead of with Eventlet. To get a more concrete integration example, you can take inspiration from Nova patches [5][6] to see how to implement your backend switch on your deliverables. A comprehensive guide is currently under creation. [7] Next steps will be to address a couple of remaining comments, to introduce functional tests, and to democratize the usages of this new backend. Thank you to Daniel for his hard work and all his efforts on this topic. Also I wanted to specially thank Gibi and Rodolfo for their close collaborations on this new backend implementation. Please join me to warmfully thank them. Our mission is to equip the community with everything it needs to leave Eventlet behind. This backend is only a tiny piece of this giant puzzle. Your turn to place your piece: https://removal.eventlet.org Cheers, [1] https://review.opendev.org/c/openstack/releases/+/950646 [2] https://review.opendev.org/c/openstack/oslo.service/+/945720 [3] https://review.opendev.org/c/openstack/requirements/+/950653 [4] https://review.opendev.org/c/openstack/devstack/+/948436 [5] https://review.opendev.org/c/openstack/nova/+/948311 [6] https://review.opendev.org/c/openstack/nova/+/948450 [7] https://review.opendev.org/c/openstack/oslo.service/+/940664 -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

"quantum" package name on pypi
by JDK Phoenix 21 May '25

21 May '25

Dear Openstack-Team, I am the creator and maintainer of the programming language "qb" (qb · PyPI <https://pypi.org/project/qb/>, qb <https://lschreiber.eu/qb/>) and I wanted to implement a package manager similar to how Maven, Cargo or Poetry works. I picked the name "quantum" for this program and noticed that this name was already in use on pypi for a package developed by you. This program has only a singular contribution in 2012 and seems to be inactive since then. I wanted to ask if it would be possible for you to transfer the quantum-package name on pypi to my user (Leander420). I would be very grateful if this could be possible. I thank you for your time and consideration Kind regards Leander S. Schreiber

6 6

Issue on IP Assignment on newly created VM after deleting old one
by sudeb ghosh 21 May '25

21 May '25

Hi Team, We are operating an OpenStack environment managed by Ansible. Openstack Version: Ussuri(21.2.1) OS: CentOS8 We had a volume backed VM named VM01 with IP of 10.10.10.10 for example. We required to delete the VM01 & recreate a VM named VM02 using the same volume. We used the same project & same network what we used for VM01 earlier. VM02 is getting any one available IPs from the given network. Manually i am able to detach the existing IP & attached the specific IP but its not pinging. Query: i) What is the option if i need the same IP(10.10.10.10) will be assigned to VM02 as well autometically? ii) What is fix to get the said old IP(10.10.10.10) working if i do attach manually in GUI through newtwork-interface? BR// Sudeb Ghosh 7044064878 9332034788

3 3

[watcher] Call for maintainers - MAAS integration
by Douglas Viroel 20 May '25

20 May '25

Hi everyone, At the last watcher's weekly meeting[1], the team discussed the impacts of the eventlet removal in Watcher's code, and it was brought up that the integration with MAAS (Metal As a Service) support is affected. At the moment, we do not have any active members in Watcher that have any experience with MAAS. CI also doesn't have any job running and testing this integration, and we don't have documentation of how it works. This is a call for maintainers interested in supporting MAAS in Watcher to help fill these gaps. It is worth mentioning that, as discussed in the PTG[2], we also plan to mark this integration as *experimental* once it does not provide minimal testing and documentation (this is also the case of other integrations). But we will cover this topic in a different thread. [1] https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-05-15-12.01… [2] https://etherpad.opendev.org/p/apr2025-ptg-watcher#L71 Thanks and regards, -- Douglas Viroel - dviroel

1 0