- openstack-discuss - lists.openstack.org

PTG October 2024 Registration & Schedule
by Kendall Nelson 15 Oct '24

15 Oct '24

Hello Everyone! The October 2024 Project Teams Gathering is right around the corner (October 21-25) and the schedule is being set up by your team leads! Slots are going fast, so make sure to get your time booked ASAP! As a reminder, you can find the team list on the registration page here[4]. You can find the schedule and available slots on the PTGbot website [1]. The PTGbot site is the during-event website to keep track of what's being discussed and any last-minute schedule changes. It is driven via commands in the #openinfra-events IRC channel (on the OFTC network) where the PTGbot listens. If you have questions about the commands that you can give the bot, check out the documentation here[2]. Also, if you haven’t connected to IRC before, here are some docs on how to get setup![3] Lastly, please don't forget to register[4] - It’s FREE. Please let us know if you have any questions via email to ptg(a)openinfra.dev. Thanks! -Kendall (diablo_rojo) [1] PTGbot Site: https://ptg.opendev.org/ptg.html [2] PTGbot Documentation: https://github.com/openstack/ptgbot#open-infrastructure-ptg-bot [3] Setup IRC: https://docs.openstack.org/contrib <https://docs.openstack.org/contributors/common/irc.html> [4] PTG Registration: http://ptg.openinfra.dev/

1 0

Proposal to resume weekly upstream Oslo IRC meetings.
by Daniel Bengtsson 15 Oct '24

15 Oct '24

Hi everyone, I hope you’re all doing well. I was thinking it might be a good idea to resume the weekly upstream Oslo IRC meetings, especially with the removal of eventlet, which makes it even more relevant. What do you think? Do you have any preferences for the day and time? Looking forward to your feedback! -- Daniel Bengtsson Software engineer

4 4

[openstack-ansible][ptg] Epoxy Team Gathering
by Dmitriy Rabotyagov 15 Oct '24

15 Oct '24

Hey folks! I have booked a relatively short session for next Tuesday, October 22 2024 from 16:00 to 18:00 UTC. The session will happen in a meetpad [1]. Topics for the discussion are held in etherpad [2]. We're having quite a scarce agenda this time, which mostly consist of things which were planned for previous cycles but were never accomplished. So I think we should be good with this 2 hour session for the discussion. If not, or smth will raise during the discussion, we can arrange another discussion during the PTG week. Thankfully, plenty of slots are available this time as well. Hope to see everyone interested in the project there! [1] https://meetpad.opendev.org/osa-epoxy-ptg [2] https://etherpad.opendev.org/p/osa-epoxy-ptg

1 0

RDO Dalmatian 2024.2 Released
by Amy Marrich 15 Oct '24

15 Oct '24

The RDO community is pleased to announce the general availability of the RDO build for OpenStack 2024.2 Dalmatian for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Dalmatian is the 30th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available for CentOS Stream 9 on the CentOS mirror network in: http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-dalmat… The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud SIG. The Cloud SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/dalmatian/highlights.html but here are some highlights: New Cinder driver features were added, notably, Dell PowerStore active-active support, Dell PowerStore QoS support, NetApp added support to active/active mode in ISCSI/FC drivers, HPE Nimble replication, and StorPool added support clone-across-pools capability. Added Glance support of new add/get location APIs which replaces the image-update (old location-add) mechanism for consumers like cinder and nova to address OSSN-0090 and OSSN-0065. Ironic has enhanced multiple security aspects, for example it now requires rescue passwords to be hashed, it has reduced the logged nodes information during the cleaning phase to avoid showing sensitive data, and it has hardened the communication between the ironic services and the ironic agent requiring an HTTPS url by default. All Neutron supported mechanism drivers (ML2/OVS, ML2/OVN) can now use the WSGI API module, completing the first phase of eventlet library deprecation. Nova Instances with UEFI firmware can now be launched with stateless firmware if their image has the hw_firmware_statelessproperty and if the compute services have libvirt 8.6.0 or later. OpenStack Dalmatian is not marked as Skip Level Upgrade Release Process or SLURP. According to this model (https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) this means that upgrades will only be supported from the Caracal 2024.1 release. RDO Dalmatian 2024.2 has been built and tested with the recently released Ceph 18.2.0 Reef version (https://docs.ceph.com/en/latest/releases/reef/) which has been published by the CentOS Storage SIG in the official CentOS repositories. *Note:* Follow the instructions in [RDO documentation](https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services in the same host. During the Dalmatian cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Dalmatian 2024.2 release: python-saharaclient (https://review.rdoproject.org/r/c/rdoinfo/+/54360) puppet-corosync (https://review.rdoproject.org/r/c/rdoinfo/+/53127) During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: During the Dalmatian cycle, we saw the following new RDO contributors: Roman Safronov Archana Singh pkomarov komarov Sergii Golovatiuk Milana Levy Liron Kuchlani Jaromír Wysoglad Arnau Verdaguer Andre Aranha Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 51 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: Alfredo Moralejo Alonso Amy Marrich Ananya Banerjee Andre Aranha Archana Singh Arnau Verdaguer Artom Lifshitz Arx Cruz Bhagyashri Shewale Bohdan Dobrelia Cédric Jeanneret Chandan Kumar Daniel Pawlik Douglas Viroel Fabien Boucher Fiorella Yanac Francesco Pantano Goutham Pacha Ravi Gregory Thiemonge Grzegorz Grasza Harald Jensås Jaromír Wysoglad Joan Francesc Gilabert Joel Capitao Jon Schlueter Karolina Kula Karthik Sundaravel Lewis Denny Liron Kuchlani Lon Hohberger Luigi Toscano Maor Blaustein Marihan Girgis Marios Andreou Martin Kopec Martin Magr Michael Johnson Milana Levy Nicolas Hicher Pini Komarov Roman Safronov Ronelle Landy Sergii Golovatiuk Shreshtha Joshi Soniya Vyas Steve Baker Takashi Kajinami Tobias Urdin Tristan De Cacqueray Yadnesh Kulkarni Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Epoxy. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For those that do not have any hardware or physical resources, there is the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://www.rdoproject.org/community/mailing-lists/. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0

[ironic] weekly meeting canceled on Monday October 21
by Riccardo Pittau 15 Oct '24

15 Oct '24

Hello everyone! As per subject, next weekly ironic community meeting won't happen as it conflicts with the PTG See you all at the PTG instead! Ciao Riccardo

1 0

[Glance][PTG] Glance Epoxy/2025.1 vPTG Schedule
by Pranali Deore 14 Oct '24

14 Oct '24

Hello All, Epoxy (2025.1) virtual PTG is going to start next week and we have created our PTG etherpad [1] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots especially for the cross project sessions. Friday is reserved for any unplanned discussions. So please feel free to add your topics if you haven't added yet. NOTE: At the moment we don't have any sessions scheduled on Friday, if there are any last moment request(s)/topic(s) we will discuss that on Friday else we will conclude our PTG on Thursday 24th OCT. The meeting URL is mentioned in etherpad [1] and will be the same throughout the PTG. [1]: https://etherpad.opendev.org/p/oct2024-ptg-glance Hope to see you there!! Thanks & Regards, Pranali Deore

1 0

[neutron] Bug Deputy report week 41 (October 7-13)
by Lajos Katona 14 Oct '24

14 Oct '24

Hi Neutrinos, Here is the bug deputy report of the last week (week 41, October 7-13). It was a really lightweight week from the incoming bug number perspective. * https://bugs.launchpad.net/neutron/+bug/2083832 ([OVN] Host_id value on lsp for router gateway is not updated on failover ) ** In Progress: https://review.opendev.org/c/openstack/neutron/+/931632 Best Wishes Lajos Katona (lajoskatona)

1 0

#eventlet-removal - Progress & Update
by Herve Beraud 14 Oct '24

14 Oct '24

We’re excited to share the latest updates on our ongoing efforts to phase out Eventlet across our various OpenStack projects. Below you’ll find a summary of our progress, key milestones, and important dates to keep in mind as we move forward with this critical initiative. ## Current Status We’ve completed the initial analysis phase across more than 120 OpenStack projects. This includes identifying the various patterns where Eventlet is currently in use and evaluating where it can be safely removed or disabled. Here are some highlights: - Completed Analysis: Projects where Eventlet is used include (but are not limited to): Aodh, Barbican, Nova, Neutron, Tacker, Taskflow, Trove, Venus, Watcher, and Zun. - Eventlet Optional: Several projects have been identified where Eventlet seems to be optional and can be disabled with minimal impact. For these projects, we will move forward the discussion with teams to try deactivating Eventlet in upcoming updates. Once done, projects of this kind would be able to start their migration with more serenity. - Eventlet Required: Some projects still rely heavily on Eventlet for core functionality. For these, we are going to develop specific migration plans. ## Migration Plans in Progress - oslo.db: Preparing its Asyncio based engine facade; - oslo.service: Refactoring plans being discussed to minimize disruption during the migration; - glance: Refactoring code to use native thread model rather than Eventlet More details can be found here: https://review.opendev.org/q/topic:%22eventlet-removal%22 ## Latest Updates - Community Goal Transition: The ongoing community goal for removing Eventlet is now in the process of becoming an official "selected" goal, https://review.opendev.org/c/openstack/governance/+/931254. - Pattern Identification Completed: We’ve identified key patterns related to Eventlet usage, including its common integration with monkey_patch(), eventlet.Timeout, eventlet.GreenPool, and eventlet.wsgi.server(). Visit the official wiki to get more details https://wiki.openstack.org/wiki/Eventlet-removal#Identifying_Common_Pattern ## Important Dates - October 21st: cross PTG session. - October 23rd: cross PTG session (Q&A session and Open Discussion session) ## Call to Action We need your involvement to accelerate the progress of this initiative! If your project is affected by Eventlet, now is the time to start planning your migration. Teams are encouraged to take immediate steps in assessing how to deactivate Eventlet or to transition to alternative solutions. We defined key roles and responsibilities. Those will help us to lower the cost of the migration for our community. Teams are invited to assign them now. Being ready as soon as possible will allow you to better take advantage of the coming PTG sessions. Please find more details about these roles and their short terms tasks: https://wiki.openstack.org/wiki/Eventlet-removal#Roles_and_Responsibilities ## Final Thoughts This is a significant step forward for improving the stability, scalability, and maintainability of our projects. With your continued support, we’re confident that this migration will bring substantial benefits to the OpenStack community. If there are any questions or if you need assistance with your project’s transition away from Eventlet, please join the discussion on the #eventlet-removal channels (OpenStack irc, RedHat slack, mailing list). Thank you for your dedication and hard work! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

7 8

[all] Runtime dependency on setuptools
by Thomas Goirand 14 Oct '24

14 Oct '24

Hi, A large number of OpenStack projects have a requirement on setuptools. In most cases, this is just a mistake, and it can be removed. This is currently a huge pain for downstream distributions that have to patch this out from requirements.txt, as we're trying to remove python3-pkg-resources which is currently deprecated, and that is added when setuptools is there. Example affected projects: - freezerclient - placement - magnum - oslotest - ... Sending the patches upstream will be too much effort, so I'll write Debian specific patches in the mean time. Please fix your project if you can. Cheers, Thomas Goirand (zigo)

1 0

[neutron] Cancelling CI Meeting for today
by Yatin Karel 14 Oct '24

14 Oct '24

Hello Neutron Team !! I will not be able to chair the CI meeting today as I will be out. Sorry for the late notice. We have some known issues in CI where jobs fail randomly, all are known ones and are being looked upon. A consistent issue in stable/2023.2 openstacksdk periodic job for which i reported[1] [1] https://bugs.launchpad.net/openstacksdk/+bug/2084427 -- Thanks and Regards Yatin Karel

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-24)
by Goutham Pacha Ravi 13 Oct '24

13 Oct '24

Hello Stackers, The Virtual Project Team Gathering (PTG) is next week [1][2]. There are 32 discussion tracks planned throughout the week, along with ad-hoc virtual hallway/water cooler discussions. As a result, many regular weekly IRC meetings will be canceled. Please take a moment to review the PTG Etherpad for the Technical Committee [3]. We encourage community-wide participation on topics such as: - Community Leaders Meeting (2024-10-21 / 1400 UTC): This event is open to all project maintainers, especially PTLs and DPLs. We'll cover several topics of community-wide importance. - Eventlet Removal (2024-10-21 / 1500 UTC): This session will kick off discussions around addressing the technical debt associated with OpenStack services migrating away from the eventlet library. - ...and many more! There may be some minor changes to the schedule based on other cross-project topics being planned. The best way to stay up-to-date is to join OFTC's #openinfra-events channel or watch the event stream on the PTG website [2]. This week, Indiana University will be hosting the OpenInfra community for OpenInfra Days, North America (15-16 Oct 2024). This is a hybrid event, and both in-person and online registrations are still open. If you're attending in person, I’d love to catch up and discuss how the OpenStack TC can assist you. Please don’t hesitate to say hello! === Weekly Meeting === The OpenStack Technical Committee held its weekly meeting on 2024-10-08 [5]. The meeting was well attended. During the meeting, we approved a change to mark the "kuryr-kubernetes" and "kuryr-tempest-plugin" projects as "inactive." This means we won’t be producing any releases from these projects during the 2025.1 "Epoxy" release cycle, and the repositories may soon be retired. If you depend on these projects, please let us know. It’s worth noting that there have been no releases since the 2024.1 "Caracal" cycle. The TC also spent time brainstorming PTG topics and scheduling. We discussed a regression in python-openstackclient that necessitates an update to the recently released 2024.2 "Dalmatian" release. We took action to strengthen the CI jobs for python-openstackclient, adding more scenarios such as upgrade testing with "trunk." The next weekly IRC meeting of the OpenStack Technical Committee is on 2024-10-15, chaired by Dmitriy Rabotyagov (noonedeadpunk). The agenda is available on the meeting wiki page [6]. I hope you can join us. Please remember that you can propose topics by editing the wiki page, and if you do, please include your IRC nick so we can call on you during the meeting. === Governance Proposals === ==== Merged ==== - Mark kuryr-kubernetes and kuryr-tempest-plugin inactive: https://review.opendev.org/c/openstack/governance/+/929698 ==== Open for Review ==== - Propose to select the eventlet-removal community goal: https://review.opendev.org/c/openstack/governance/+/931254 - Propose a pop-up team for eventlet-removal: https://review.opendev.org/c/openstack/governance/+/931978 - Adding Axel Vanzaghi as PTL for Mistral: https://review.opendev.org/c/openstack/governance/+/927962 === How to Contact the TC === You can reach the TC in several ways: 1. Email: Send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel. 3. Join us at our weekly meeting: The Technical Committee meets every Tuesday at 1800 UTC [6]. --- === Upcoming Events === - 2024-10-15: OpenInfra Days NA, Indianapolis [4] - 2024-10-21: OpenInfra Project Teams Gathering: https://openinfra.dev/ptg/ Thank you for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] "Epoxy" PTG Schedule: https://ptg.opendev.org/ptg.html [3] OpenStack TC PTG Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [4] OpenInfra Days North America: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ [5] TC Meeting IRC Log, 2024-10-08: https://meetings.opendev.org/meetings/tc/2024/tc.2024-10-08-18.00.log.html [6] TC Meeting Agenda, 2024-10-15: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[manila] how to connect ceph backend with manila
by Shubham Kumar Yadav 12 Oct '24

12 Oct '24

hello, I'm trying to install manila in my openstack cloud (deployed on k8s cluster) but having problem. 1 -> i created the auth using ceph auth get-or-create client.manila -o manila.keyring \ mgr 'allow rw' \ mon 'allow r' source - https://docs.openstack.org/manila/latest/configuration/shared-file-systems/… 2 -> in manila-share pod i see the error 2024-10-08 07:37:25.090 7 INFO manila.share.drivers.cephfs.driver [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] [CEPHFSNATIVE1] Ceph client found, connecting... 2024-10-08 07:37:25.104 7 ERROR manila.share.manager [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] Error encountered during initialization of driver CephFSDriver@lab-11053-26006-ceph-1@cephfsnative1: manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. 2024-10-08 07:37:25.104 7 ERROR manila.share.manager Traceback (most recent call last): 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 421, in rados_client 2024-10-08 07:37:25.104 7 ERROR manila.share.manager self._rados_client.connect() 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "rados.pyx", line 690, in rados.Rados.connect 2024-10-08 07:37:25.104 7 ERROR manila.share.manager rados.IOError: [errno 5] RADOS I/O error (error connecting to the cluster) 2024-10-08 07:37:25.104 7 ERROR manila.share.manager 2024-10-08 07:37:25.104 7 ERROR manila.share.manager During handling of the above exception, another exception occurred: 2024-10-08 07:37:25.104 7 ERROR manila.share.manager 2024-10-08 07:37:25.104 7 ERROR manila.share.manager Traceback (most recent call last): 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/manager.py", line 371, in _driver_setup 2024-10-08 07:37:25.104 7 ERROR manila.share.manager self.driver.do_setup(ctxt) 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 274, in do_setup 2024-10-08 07:37:25.104 7 ERROR manila.share.manager rados_client=self.rados_client, 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 424, in rados_client 2024-10-08 07:37:25.104 7 ERROR manila.share.manager raise exception.ShareBackendException( 2024-10-08 07:37:25.104 7 ERROR manila.share.manager manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. 2024-10-08 07:37:25.104 7 ERROR manila.share.manager 2024-10-08 07:37:25.105 7 DEBUG manila.utils [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] Finished call to 'manila.share.manager.ShareManager.init_host.<locals>._driver_setup' after 62.106(s), this was the 6th time calling it. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/after.py:44 2024-10-08 07:37:25.105 7 DEBUG manila.utils [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] Retrying manila.share.manager.ShareManager.init_host.<locals>._driver_setup in 64.0 seconds as it raised ShareBackendException: [%(be)s] Ceph client failed to connect.. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/before_sleep.py:65 3 -> when i try to use the maila keyring i get the error *[rook@cmp-2 ceph]$ ceph --key AQBip/9mCMf4N/jFNKFlwl/hA4j64esWuA== osd ls[errno 13] RADOS permission denied (error connecting to the cluster)*this is what i get after running that not sure what permissions any idea? -> i also tried with admin rights to the auth *[rook@cmp-2 ceph]$ ceph auth get client.manila[client.manila] key = AQBip/9mCMf4N/jFNKFlwl/hA4j64esWuA== caps mds = "allow *" caps mgr = "allow *" caps mon = "allow *" caps osd = "allow *"exported keyring for client.manila * 4-> my manila conf looks like conf: manila: DEFAULT: debug: true enabled_share_protocols: NFS,CIFS,CEPHFS enabled_share_backends: cephfsnative1 cephfsnative1: driver_handles_share_servers: False share_backend_name: CEPHFSNATIVE1 share_driver: manila.share.drivers.cephfs.driver.CephFSDriver cephfs_conf_path: /etc/ceph/ceph.conf cephfs_protocol_helper_type: CEPHFS cephfs_auth_id: manila cephfs_cluster_name: rook-ceph cephfs_filesystem_name: myfs any idea what could be wrong? Hope to hear from you soon Thank you!

2 1

[manila] Oct 17th and 24th weekly meeting canceled
by Carlos Silva 11 Oct '24

11 Oct '24

Hello Zorillas! As mentioned in the previous Manila weekly meeting, the Oct 17th meeting is being cancelled, as a couple of people from the audience won't be able to join. The Oct 24th weekly meeting is being cancelled because it is the PTG week, and we will be meeting on several time slots during that week [1]. [1] https://ptg.opendev.org/ptg.html Thank you! Regards, carloss

1 0

[all] Looking for low hanging fruits bugs for first time contributors
by Carlos Silva 11 Oct '24

11 Oct '24

Hello, stackers! Next week, Goutham and I will be hosting a workshop at the OpenInfra Days North America for new contributors, where we are focusing on getting people to submit code to OpenStack projects for the first time. For that, we would like to create a pool of low-hanging-fruit bugs from multiple projects that the attendees could choose what bug they would like to spend some time on fixing. We would like to extend this to all projects, so we would like to ask for your much needed help: If you are aware of an unassigned low hanging fruit bug in the project you are maintaining that could be easily fixed, it would be of much help if you please add it to this etherpad [1], alongside a comment mentioning how you imagine the fix for it. If we don't get assignees this time, no worries, we are always trying to get similar types of bugs for onboarding in our internship initiatives, so it can be picked up later. [1] https://etherpad.opendev.org/p/lhf-bugs-openinfra-days-na Thank you very much for your help! carloss

4 4

[release] Release countdown for week R-24, Oct 14 - 18
by Elõd Illés 11 Oct '24

11 Oct '24

Hi, Welcome back to the release countdown emails! These will be sent at major points in the 2025.1 Epoxy development cycle, which should conclude with a final release on April 2nd, 2025. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2025.1 Epoxy development cycle, assessing 2025.1 Epoxy community goals and approving 2025.1 Epoxy specs. General Information ------------------- 2025.1 Epoxy is a 26 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/epoxy/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2024.2 Dalmatian release are continued in 2025.1 Epoxy with a similar release model. Upcoming Deadlines & Dates -------------------------- Project Teams Gathering: October 21-25, 2024 Epoxy-1 milestone: November 14th, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla] Weekly meeting 16th Oct cancelled
by Michał Nasiadka 11 Oct '24

11 Oct '24

Hello Koalas, Cancelling weekly meeting on 16th October due to OpenInfra Days USA (Indianapolis). The next meeting (23rd October) is also cancelled because we’ll be meeting on Kolla vPTG (https://etherpad.opendev.org/p/kolla-epoxy-ptg) Please propose PTG topics and see you there! Michal

1 0

[PTG][ironic] APAC timezone friendly slot
by Riccardo Pittau 10 Oct '24

10 Oct '24

Hello ironicers! The PTG is getting closer, it's just 10 days away! This time too the ironic team would like to have an APAC timezone friendly slot to allow operators, contributors, and in general anyone interested in ironic from that timezone to be able to hear about the current ironic project direction, propose and discuss topics, or just listen to what's in the plans for epoxy. Looking at the current schedule we can place such a slot on Tuesday 21 or Wednesday 22, and of course we'd like to hear from whoever is interested for potential suited times. Don't hesitate to reply here or contact the ironic team in our IRC channel #openstack-ironic Thanks! Ciao Riccardo (rpittau)

1 0

Kolla Ansible on Ubuntu 20.04 - cloud-init & other network issues
by Tobias McNulty 10 Oct '24

10 Oct '24

Hi, I'm attempting to use Kolla Ansible 14.6.0 to deploy OpenStack Yoga on a small 3-node Ubuntu 20.04 cluster. The nodes have 128 GB RAM each, dual Xeon processors, and dual 10G Intel NICs. The NICs are connected to access ports on a 10G switch with separate VLANs for the local and external networks. All the playbooks run cleanly, but cloud-init is failing in the Ubuntu 20.04 and 22.04 VMs I attempt to boot. The VM images are unmodified from https://cloud-images.ubuntu.com/, and cloud-init works fine if I mount a second volume with user-data. The error is a timeout attempting to reach 169.254.169.254. This occurs both when booting a VM in an internal routed network and directly in an external network. I tried various neutron plugin agents (ovn, linuxbridge, and openvswitch both with and without firewall_driver = openvswitch <https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro…>) first with a clean install of the entire OS each time, all with the same result. Running tcpdump looking for 169.254.169.254 shows nothing. As a possible clue, the virtual NICs are unable to pass any traffic (e.g., to reach an external DHCP server) unless I completely disable port security on the interface (even if the associated security group is wide open). But disabling port security does not fix cloud-init (not to mention I don't really want to disable port security). Are there any additional requirements related to deploying OpenStack with Kolla on Ubuntu 20.04? This is a fairly vanilla configuration using the multinode inventory as a starting point. I tried to follow the Quick Start <https://docs.openstack.org/kolla-ansible/yoga/user/quickstart.html> as closely as possible; the only material difference I see is that I'm using the same 3 nodes for control + compute. I am using MAAS so it's easy to get a clean OS install on all three nodes ahead of each attempt. I plan to try again with the standard (non-HWE) kernel just in case, but otherwise I am running out of ideas. In case of any additional clues, here are my globals.yml and inventory file, along with the playbook I'm using to configure the network, images, VMs, etc., after bootstrapping the cluster: https://gist.github.com/tobiasmcnulty/7dbbdbc67abc08cbb013bf5983852ed6 Thank you in advance for any advice! Cheers, Tobias

5 9

DevStack Installation Issue on Ubuntu (Bare Metal) - Can't add security group and floating IP
by nayeem.hossain＠enosisbd.com 09 Oct '24

09 Oct '24

Hi, I hope you're doing well. I am Nayeem from Bangladesh, and we are in the process of installing DevStack on an Ubuntu machine for a proof of concept (POC). However, after installation, we are facing issues with adding security groups and attaching floating IPs to instances in OpenStack. Additionally, we are unable to access the instance from the same LAN. Could you please assist us in resolving these issues? Thank you for your support. Best regards, Nayeem

1 0

{Horizon] Weekly meeting cancelled Oct 9
by Tatiana Ovchinnikova 09 Oct '24

09 Oct '24

Hi team, As we have discussed last week, today's meeting is cancelled. See you next week! With kind regards, Tatiana

1 0

Operators
by engineer2024 09 Oct '24

09 Oct '24

I can't the openstack operators mailing list. Can someone please point me in the right direction?

5 4

Improving stestr... or switching to a (better) compatible test runner?
by Thomas Goirand 09 Oct '24

09 Oct '24

Hi, This is the 2nd time I'm opening a thread about it. Sorry for this, but it really bothers me. Today, running tempest, I got these stats from stestr: - Worker 0 (132 tests) => 0:24:49.209885 - Worker 1 (100 tests) => 0:17:14.791845 - Worker 2 (124 tests) => 0:42:52.690906 - Worker 3 (189 tests) => 0:41:21.307241 - Worker 4 (159 tests) => 0:45:49.503031 - Worker 5 (143 tests) => 0:28:13.282371 - Worker 6 (156 tests) => 3:16:52.364976 - Worker 7 (103 tests) => 0:46:05.366089 So, thread #1 ran 17 minutes, sitting idle for the rest of the 3 hours run of thread #6. While I thought stestr was deviding the number of tests by the number of thread, I don't get why worker #1 only had 100 tests assigned. All together, all tests could have been ran within maybe less than an hour of time (rather than 3h16 above), if not-yet-ran-tests were reassigned to idle treads. I'm currently spending a lot of time on running tempest. Indeed, I'm running tempest on each OpenStack upgrade, from Victoria up to Dalmatian. With the current way stestr run, it may take 2 full days to do that (and that's not even counting when upgrade will fail and will need fixing...), when it could be done in maybe 8 hours (if I count 1h per OpenStack release). So, knowing the above, it might be a good use of my time to dig into stestr and see if I can fix this... or not! Does anyone have a suggestion for another test runner, that's compatible with stestr, at least for the tests selection with a regular expression? As much as I know, pytest cannot take a regexp for test selection, can it? Or is there maybe a plugin for it? If there's no compatible test runner, where should I dig in the stestr code to rewrite things in a smarter way? Cheers, Thomas Goirand (zigo) P.S: On Caracal today, I just had this: ============== Worker Balance ============== - Worker 0 (117 tests) => 0:59:32.291385 - Worker 1 (147 tests) => 1:22:28.228980 - Worker 2 (125 tests) => 0:45:20.969397 - Worker 3 (114 tests) => 1:46:21.667579 - Worker 4 (170 tests) => 0:45:27.577738 - Worker 5 (190 tests) => 2:28:39.744920 - Worker 6 (182 tests) => 2:29:01.402255 - Worker 7 (152 tests) => 2:29:10.183359 this looks better, but that's probably 1/ random 2/ still not perfect, with worker #0, #2 and #4 doing nothing 2/3rd of the time.

2 1

[tc][watcher] No leaders for project team, heading to retirement
by Goutham Pacha Ravi 09 Oct '24

09 Oct '24

Hello Stackers, The "watcher" project [1] did not have any volunteers to lead the project in the 2025.1 election cycle. In the past few years, the project's team has slowly disbanded and there have been no significant changes proposed/merged in the project's repositories [2]. We noticed that there were three deployers that noted their use of Watcher in production in the past user survey [3]. It's possible that the project failed to gather any significant adoption, and hence there's less interest in contributing to, and maintaining the project. I'm sending this notification pursuant to the OpenStack governance recommendations [4] to retire project teams. We can mark a project team "inactive", however, an "inactive" project must have some contributors aiming to build-back a maintainers team around it - and it must pick a project team lead, or adopt a distributed project leadership model by nominating liaisons. Since there are no PTL nominees, we think marking this project "inactive" serves no purpose. Is there any objection to retiring the "openstack/watcher" project (and associated deliverables: python-watcherclient, watcher-dashboard and watcher-tempest-plugin)? Once the project is retired, configuration management and deployment projects can drop their integrations as well. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi [1] https://wiki.openstack.org/wiki/Watcher [2] https://review.opendev.org/q/(project:%5Eopenstack/watcher.*+OR+project:ope… [3] https://governance.openstack.org/tc/user_survey/analysis-2023.html [4] https://governance.openstack.org/tc/reference/dropping-projects.html

5 7

[all][manila][ironic][swift][bandit] removal of Python standard libraries in Python 3.13
by Thomas Goirand 08 Oct '24

08 Oct '24

Hi, OpenStack Dalmatian is currently fully in Debian Testing, and in a quite good shape. However, as you may know, Python 3.13 is about to be uploaded to Debian unstable, and we intend to release Debian 13 (aka: Trixie) with it. A number of OpenStack (or related) packages are affected by the removal of Python standard libraries in Python 3.13. We need to fix these ASAP (and not only because of Debian). Here's the list of affected projects, with the name of the bad import that was removed from Python 3.13: manila https://bugs.debian.org/1084543 (pipes) swift https://bugs.debian.org/1084544 (cgi) ironic https://bugs.debian.org/1084566 (crypt) ironic-python-agent https://bugs.debian.org/1084680 (crypt) bandit https://bugs.debian.org/1084700 (crypt, telnetlib) There's also a number of libraries that we don't directly maintain, but that are in our requirements: qpid-proton https://bugs.debian.org/1084552 (cgi) python-wsme https://bugs.debian.org/1084594 (cgi) python-falcon https://bugs.debian.org/1084623 (cgi) python-pysaml2 https://bugs.debian.org/1084670 (cgi) These will need to be fixed. For more details with were the bad import was found, please dive into the individual bug reports. While pipes and crypt have direct replacement (subprocess and for example the pypi module bcrypt), there's a few comments here: https://docs.python.org/3.13/whatsnew/3.13.html While I will for sure attempt to fix some of the above, I cannot be held responsible for all of OpenStack code, and I'd appreciate a lot having some help. Unless I'm being pointed at fixes patches in Gerrit, I'll start filling bugs for the above once I'm done with other tasks (currently, I'm working on validation of OpenStack upgrades in Debian), and hopefully, get all in order before Trixie's freeze in early 2025. I know there's probably going to be more Python 3.13 fixes to come, and I expect some package to fail to build from source (FTBFS) due to some tests failing in 3.13. Then I'll run my usual tempest validation CI, and hopefully, Dalmatian on Trixie will be the best OpenStack ever... :) In the mean time, let's tackle the above. Cheers, Thomas Goirand (zigo)

7 7

[publiccloud-sig] Heads-Up: next meeting October 9th (tomorrow) - 0700 UTC
by Felix Kronlage-Dammers 08 Oct '24

08 Oct '24

Hi everyone, This Wednesday, tomorrow, (October 9th) the next meeting of the publiccloud-sig is going to happen. Thanks to Artem (gtema) and Joern (joek-office) who helped prepare the meeting agenda for this wednesday: - Housekeeping - Upcoming vPTG - Reminder to sign up for PTG: https://openinfra.dev/ptg/ - CfPs for Devrooms @ FOSDEM 2025 -> Sovereign Cloud Devroom? - Continued discussion regarding IAM Federation If you’re interesting in IAM federation, be sure to join! We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> Due to vacation, I’ll not be around so I wish a fruitful meeting :) felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0