October 2024 - openstack-discuss - lists.openstack.org

[all][qa] Moving grenade to install things in venv: Enable GLOBAL_VENV
by Ghanshyam Mann 17 Oct '24

17 Oct '24

Hello Everyone, Since 2023.2 devstack by default, installs things in virtual env and due to the old node was not ready in the grenade job, we disabled that with the flag GLOBAL_VENV. Now it is time to enable it in greande also. This also fixes the failure we are getting in the grenade setup for the current master (upgrade testing from stable/2024.2 -> master) which is setuptool error for projects that have pyproject.toml[1]. I have proposed the changes in granade, but at least Octavia, Ironic, and heat jobs are failing. I have proposed some fixes for these projects. - https://review.opendev.org/q/topic:%22grenade-venv%22 I would like to request the project to test their grenade jobs with https://review.opendev.org/c/openstack/grenade/+/930507 and fix the failure if any. I would like to merge the grenade change as soon as its gate passes so that we can set up the grenade testing correctly for the current master. If any project requires a large change/more time to make their grenade jobs work in venv then you can disable the GLOBAL_VENV there for the time being and enable it once things work. [1] https://zuul.opendev.org/t/openstack/build/517b21fc57d6480f902273e58f9032b5 -gmann

1 1

[Glance] Cancelling weekly meetings Today and Next week
by Pranali Deore 17 Oct '24

17 Oct '24

Hello Team !! I won't be able to chair today's meeting, I will be out for some personal reason and also there is nothing much on agenda for this week, So cancelling the meeting for today. Sorry for the last minute update ! Next week's meeting is also cancelled because of the PTG session. So you all next week!! Thanks & Regards, Pranali Deore

1 0

[keystone] What does a multi-region service catalog look like?
by Stephen Finucane 17 Oct '24

17 Oct '24

o/ The question in $subject came up in a discussion earlier today and I neither knew the answer nor was able to discover it by looking at a service catalogs for a few production deployments I have access to (also, the multi-region feature is currently broken in DevStack and likely has been for some time). Crucially, in a "standard" multi-region deployment where there is one Keystone instances and N Nova/Cinder/Glance/Neutron/... deployments, would I have something like the below, where there is only one identity endpoint but multiple e.g. compute endpoints, or would I expect there always to be as many identity endpoints as there are e.g. compute endpoints? { "token": { ... "catalog": [ { "endpoints": [ { "id": "fb757b386a23430d8f4d636b8b45fa89", "interface": "public", "region_id": "RegionOne", "url": "http://10.0.110.125/identity", "region": "RegionOne" } ], "id": "50c4feff9d6149b898fce20ce23904a3", "type": "identity", "name": "keystone" }, { "endpoints": [ { "id": "2ed0cb59adb0415c948f8351b6546d3e", "interface": "public", "region_id": "RegionOne", "url": "http://10.0.110.125/compute/v2.1", "region": "RegionOne" }, { "id": "2ed0cb59adb0415c948f8351b6546d3e", "interface": "public", "region_id": "RegionTwo", "url": "http://10.0.112.232/compute/v2.1", "region": "RegionOne" } ], "id": "87322637c5ab4e7b90bea7a8c1eb9525", "type": "compute", "name": "nova" }, ... ] } } I'm guessing the latter, but I'd like to confirm this. Stephen

3 4

[privsep][nova] howto enable privsep logs in nova
by Benedikt Trefzer 16 Oct '24

16 Oct '24

Hi List I'd like to enable log messages for privsep executions. Currently a log file is created (/var/log/nova/privsep.log) but no content is ever written to it. How do I enable the log (Warning/Info/debug) messages to be written into that file ? Thanks for any hint Benedikt

1 0

[largescale-sig] Next meeting: October 16, 9utc
by Thierry Carrez 16 Oct '24

16 Oct '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20241016T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[manila] CephFS Driver Failing to Connect in Manila on OpenStack
by Shubham Kumar Yadav 16 Oct '24

16 Oct '24

Hi, im trying to install Manila (helm chart) in my Openstack cloud but getting some errors. If you could please help me with those. Im following this doc - https://docs.openstack.org/manila/latest/configuration/shared-file-systems/… 1 - 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 2 - So i created the auth using (according to document) ceph auth get-or-create client.manila -o manila.keyring \ mgr 'allow rw' \ mon 'allow r' 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 - and also 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 any idea what could be wrong? or if there's a better guide available Hope to hear from you soon Thank you!

1 0

[octavia] cancelling weekly meetings today and next week
by Gregory Thiemonge 16 Oct '24

16 Oct '24

Hi Folks, Many contributors have a conflict today with the Octavia weekly meeting, so we are cancelling it. Next week's meeting is also cancelled because of the PTG session on the same day. Thanks, Greg

1 0

Invitation: [openstack-ansible][ptg] Epoxy Team Gathering @ Tue Oct 22, 2024 6pm - 8pm (CEST) (openstack-discuss@lists.openstack.org)
by Hosam Al Ali 16 Oct '24

16 Oct '24

[openstack-ansible][ptg] Epoxy Team Gathering Tuesday Oct 22, 2024 ⋅ 6pm – 8pm Central European Time - Stockholm Join with Google Meet https://meet.google.com/jjg-hwhi-vqg?hs=224 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 Organizer Hosam Al Ali a.hosam(a)gmail.com Guests Hosam Al Ali - organizer openstack-discuss(a)lists.openstack.org noonedeadpunk(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=MHI1YzRhcTNzbTI1… Reply for openstack-discuss(a)lists.openstack.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=MHI1YzRhcTNzbTI1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 0

[tc] Weekly IRC meeting on October 22, 2024 is cancelled
by Dmitriy Rabotyagov 16 Oct '24

16 Oct '24

Hi everyone, Due to the PTG [1] which is taking place next week (October 21-25) and TC has already planned to have 2 sessions (you can check on agenda [2] and join us there), it was agreed to skip our regular IRC meeting on October 22. Next TC meeting in IRC channel #openstack-tc on OFTC network is planned on October 29, 2024. [1] https://openinfra.dev/ptg/ [2] https://etherpad.opendev.org/p/oct2024-ptg-os-tc

1 0

[kuryr][tc] Final call for Kuryr PTL/DPL liaisons
by Ghanshyam Mann 16 Oct '24

16 Oct '24

Hello Everyone, Kuryr project ends up being a leaderless project for the 2024.2 Dalmatian cycle[1]. There is no volunteer to serve as PTL or DPL liaisons yet. As the next step, I have proposed to mark this project Inactive: - https://review.opendev.org/c/openstack/governance/+/916945 If you would like to serve as a leader and help maintain this project, this is the right time to step up by replying to this email or commenting in gerrit change 916945. [1] https://etherpad.opendev.org/p/2024.2-leaderless#L99 Ref: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -gmann

4 10

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

16 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 16 Oct '24

16 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 15 Oct '24

15 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 12 Oct '24

12 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 12 Oct '24

12 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 10 Oct '24

10 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 09 Oct '24

09 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 09 Oct '24

09 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

Configuring Multiple IdPs with OpenStack and Shibboleth
by Abubakur Sait 08 Oct '24

08 Oct '24

Hello everyone, I have successfully configured a single Shibboleth Federation system with OpenStack (using a single IdP and SP) on a DevStack deployment. Now, I’m looking to expand the setup to support multiple IdPs with OpenStack. I followed the instructions on the Shibboleth SessionInitiator page ( https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334685/SessionIn…) but I haven’t had any success so far. Does anyone have experience or suggestions on how to configure multiple IdPs in this setup? Thank you in advance for any guidance! Best regards, Abubakur Sait

1 0

How to create snapshot via Python module
by Saeed Fazlollahzadeh 08 Oct '24

08 Oct '24

Hello, this is my full code to create a snapshot from an instance. The code creates a new image with type snapshot, but after around 2 hours, its status is still in queue. But when I create another snapshot via the Openstack UI, it works fine. Would you please help me how can I create a snapshot? import openstack import datetime now = datetime.datetime.now() today = now.strftime('%Y_%m_%d_%H_%M_%S') openstack.enable_logging(debug=False) servers = [] images = [] openstack_connection = openstack.connect(cloud='region1') # clouds.yaml for server in openstack_connection.compute.servers(details=True, hostname='my_server'): servers.append(server.to_dict()) servers = servers[0] for image in openstack_connection.compute.images(details=True, id=servers['image']['id']): images.append(image.to_dict()) images = images[0] name = f'my_server_{today}' openstack_connection.image.create_image( name=name, disk_format='raw', container_format='bare', visibility='private', timeout=1, properties={ 'hw_disk_bus': 'scsi', 'hw_qemu_guest_agent': 'yes', 'hw_scsi_model': 'virtio-scsi', 'hw_watchdog_action': 'reset', 'base_image_ref': servers['image']['id'], 'owner_user_name': 'whmcs', 'owner_project_name': 'admin', 'boot_roles': 'admin,reader,member', 'os_admin_user': 'administrator', 'os_distro': 'windows', 'os_type': 'windows', 'owner_specified.openstack.object': images['metadata']['owner_specified.openstack.object'], 'clean_attempts': '1', 'hw_machine_type': 'pc', 'password_0': '', 'password_1': '', 'password_2': '', 'password_3': '', 'hw_cdrom_bus': 'ide', 'hw_input_bus': 'usb', 'hw_pointer_model': 'usbtablet', 'hw_video_model': 'virtio', 'hw_vif_model': 'virtio', 'instance_uuid': servers['id'], 'image_type': 'snapshot', } )

2 2

How to create snapshot via python module?
by Saeed 08 Oct '24

08 Oct '24

Hello, this is my full code to create a snapshot from an instance. The code creates a new image with type snapshot, but after around 2 hours, its status is still in queue. But when I create another snapshot via the Openstack UI, it works fine. Would you please help me how can I create a snapshot? import openstack import datetime now = datetime.datetime.now() today = now.strftime('%Y_%m_%d_%H_%M_%S') openstack.enable_logging(debug=False) servers = [] images = [] openstack_connection = openstack.connect(cloud='region1') # clouds.yaml for server in openstack_connection.compute.servers(details=True, hostname='my_server'): servers.append(server.to_dict()) servers = servers[0] for image in openstack_connection.compute.images(details=True, id=servers['image']['id']): images.append(image.to_dict()) images = images[0] name = f'my_server_{today}' openstack_connection.image.create_image( name=name, disk_format='raw', container_format='bare', visibility='private', timeout=1, properties={ 'hw_disk_bus': 'scsi', 'hw_qemu_guest_agent': 'yes', 'hw_scsi_model': 'virtio-scsi', 'hw_watchdog_action': 'reset', 'base_image_ref': servers['image']['id'], 'owner_user_name': 'whmcs', 'owner_project_name': 'admin', 'boot_roles': 'admin,reader,member', 'os_admin_user': 'administrator', 'os_distro': 'windows', 'os_type': 'windows', 'owner_specified.openstack.object': images['metadata']['owner_specified.openstack.object'], 'clean_attempts': '1', 'hw_machine_type': 'pc', 'password_0': '', 'password_1': '', 'password_2': '', 'password_3': '', 'hw_cdrom_bus': 'ide', 'hw_input_bus': 'usb', 'hw_pointer_model': 'usbtablet', 'hw_video_model': 'virtio', 'hw_vif_model': 'virtio', 'instance_uuid': servers['id'], 'image_type': 'snapshot', } )

1 0

[neutron] OVS Agent constant bridges recreation
by Artsiom Antropau 08 Oct '24

08 Oct '24

Hi, Team! Pretty long time we’re experiencing some troubles with auto-restoration of ovs after some storms. We’re using neutron-wallaby and openvswitch 2.15. The problem is the next: After some storms we’re receiving situation, when ovs agent constantly recreating bridges and doing full syncs, which affects our network stability. All versions (incl. 2024.2), containing some parts of code that I want to highlight: 1. Non-empty `idl_monitor.bridges_added` triggers 2. `_do_reconfigure_physical_bridges`, then it triggers 3. `setup_physical_bridges(bridge_mappings)` then it contains 4. br.create() I’m seeing note in code «The bridge already exists, so create won't recreate it», BUT at the same time we’re receiving in logs: ``` Matched CREATE: BridgeCreateEvent(events=('create',), table='Bridge', conditions=None, old_conditions=None) to row=Bridge(name=br-tun ``` and ``` BridgeCreateEvent, bridge name: br-tun ``` Constantly – by hours and for all our bridges (we have four: br-tun, br-ex, br-int, br-rmi) while we will not restart ovs agent. So this event filling idl_monitor.bridges_added then ovs reacting on it by _do_reconfigure_physical_bridges, then it triggers br.create() and we’re receiving event once again – we’re in loop. Want to add that our datapath-id NOT changing between these runs – keeps same. Any ideas or ways how to fix this problem and never experience it next? [https://my.gcdn.co/images/signature/gcore_logo.png]<https://gcore.com/> Artsiom Antropau Software Engineer artsiom.antropau(a)gcore.com<mailto:artsiom.antropau@gcore.com> +48796909739<tel:+48796909739> gcore.com<https://gcore.com/> [https://my.gcdn.co/images/signature/linkedin.png]<https://www.linkedin.com/company/g-core> [https://my.gcdn.co/images/signature/x.png] <https://x.com/gcore_official> [https://my.gcdn.co/images/signature/youtube.png] <https://www.youtube.com/channel/UCFhtQE7HB097a1_Nfv-Ma_Q> [https://my.gcdn.co/images/signature/facebook.png] <https://www.facebook.com/gcorelabscom/> [https://my.gcdn.co/images/signature/instagram.png] <https://www.instagram.com/gcore.official/> This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment.

2 1

image creation error
by BEDDA Fadhel 08 Oct '24

08 Oct '24

I'm trying to create a debian image for openstack from a file. on the graphical interface it still remains waiting. On the command line: I receive the message: HttpException: 502: Server Error for url: http://192.168.11.40/image/v2/images/1bb75b80-f6d2-4a26-a941-a52b03e48455/f…, : 502 Bad Gateway: Bad Gateway: The proxy server received an invalid: response from an upstream server.: Apache/2.4.52 (Ubuntu) Server at 192.168.11.40 Port 80 Merci

1 0

[manila] stuck at connecting ceph backend with manila
by Shubham Kumar Yadav 08 Oct '24

08 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!

1 0

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

08 Oct '24

Hello Stackers, This week, we begin our 26-week endeavor towards the next SLURP release, 2025.1 ("Epoxy") [1]. OpenStack Project Teams will meet virtually at the Project Teams Gathering (PTG) in two weeks, starting on 2024-10-21 [2]. The OpenStack TC plans to host cross project meetings during the following time slots: - 2024-10-21 (Monday): 1400 UTC - 1700 UTC - 2024-10-25 (Friday): 1500 UTC - 1700 UTC You'll find the proposed topics on the PTG Etherpad [3]; please add your IRC nickname if you'd like to attend or be notified when discussions begin. Last week, a few community leads presented at OpenInfra Live, recapping the 2024.2 release [4]. I encourage you to watch the presentation and follow the themes each team is pursuing in the "Epoxy" release cycle. I'm excited to share that the organizers of the upcoming OpenInfra Days North America (Oct 15-16) have made it a hybrid event. Please register if you plan to attend virtually [5]. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held simultaneously on IRC [6] and video [7]. We discussed meeting times, and the current time (Tuesdays at 1800 UTC) was retained due to a lack of consensus on better alternatives. Sylvain Bauza (bauzas) volunteered to be an Election Official for the 2025.2 elections, which will be announced around February 2025. We also discussed "leaderless" projects for the 2025.1 release and appointed leaders for the OpenStack Mistral, OpenStack Watcher, and OpenStack Swift projects. Additionally, we created a TC tracker for the 2025.1 release cycle [8] to monitor the progress of community goals and other governance initiatives. The next OpenStack Technical Committee meeting is today (2024-10-08) at 1800 UTC on the #openstack-tc IRC channel on OFTC. You can find the agenda on the weekly meeting wiki page [9]. I hope you can join us! Below is a list of governance changes that have merged in the past week and those still pending community review. === Governance Proposals === ==== Merged ==== - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 ==== Open for Review ==== - Mark kuryr-kubernetes and kuryr-tempest-plugin inactive | https://review.opendev.org/c/openstack/governance/+/929698 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Propose the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/931254 === Upcoming Events === - 2024-10-08: OpenInfra Monthly Board Meeting: https://board.openinfra.dev/ - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 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] Technical Committee PTG Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [4] "Introducing OpenStack Dalmatian 2024.2": https://youtu.be/6igJNIJ9yFE [5] OpenInfra Days NA: https://ittraining.iu.edu/explore-topics/titles/oid-iu/index.html#register [6] TC Meeting IRC Log, 2024-10-01: https://meetings.opendev.org/meetings/tc/2024/tc.2024-10-01-18.00.log.html [7] TC Meeting Video Recording, 2024-10-01: https://youtu.be/6RXE1LfEv7w [8] 2025.1 TC Tracker: https://etherpad.opendev.org/p/tc-2025.1-tracker [9] TC Meeting Agenda, 2024-10-08: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

L2 gateway
by engineer2024 07 Oct '24

07 Oct '24

I am trying to understand the L2-GW concept in openstack neutron. I understand that its primary purpose is to bridge two l2 networks into one single network. We have tenant and provider networks in neutron. 1. Why would anyone want to bridge two l2 networks in the first place ? 2. Can these two l2 networks be, two unroutable tenant networks ? Please bear with my ignorance here. I am trying to grasp and learn these concepts. Any help in this regard is much appreciated... Thanks elinux

2 2

[neutron][nova][oslo][all] Common middleware to log requests
by Takashi Kajinami 07 Oct '24

07 Oct '24

Hello, (I'm adding tags from teams which may be directly involved with this discussion but also add all tag because this topic is actually a global topic) I recently spent some time to try neutron deployments with api run by httpd and rcp-server, and I noticed that I no longer see request details logged in neutron logs. It used to be logged by WSGI server implementation in oslo.service (which heavily depends on eventlet and being removed). Based on my past experience, the information is quite important when we have to debug any problems triggered by API request (API returned 500, Tried to create a resource but it failed, etc...). WSGI server (uwsgi or apache) may have their own request loggings but the problem with these is that these do not log context details (especially request id) so analyzing logs is still difficult. I initially created https://bugs.launchpad.net/neutron/+bug/2083760 to discuss this problem in neutron. However, when I looked at a few other repos, I noticed that current implementation is quite inconsistent across projects and now I think this needs to be discussed as a more global topic. IMO the current inconsistency makes debugging quite difficult and we need more consistent logging to help operators get more consistent and detailed information. 1. Some projects (eg. aodh, designate, octavia) does not log requests 2. Other projects (eg. cinder, glance, heat) log requests in their logic but does not log some items such as remote addr and response time. 3. nova[1] and placement[2] have own request_log middleware with more complete information (but one in nova does not have debug log dumped when api starts processing the request) I'm wondering if it makes sense to import the existing request_log middleware implementation from nova/placement and use it globally (and drop the existing logging with less incomplete information to avoid redundant logs). Thank you, Takashi [1] https://github.com/openstack/nova/blob/master/nova/api/openstack/requestlog… [2] https://github.com/openstack/placement/blob/master/placement/requestlog.py -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 4

[neutron] [ovs] OVS agent constant bridge recreate flow
by Max Payne 07 Oct '24

07 Oct '24

Hi, Team! Pretty long time we’re experiencing some troubles with auto-restoration of ovs after some storms. We’re using neutron-wallaby and openvswitch 2.15. The problem is the next: After some storms we’re receiving situation, when ovs agent constantly recreating bridges and doing full syncs, which affects our network stability. All versions (incl. 2024.2), containing some parts of code that I want to highlight: 1. Non-empty `idl_monitor.bridges_added` triggers 2. `_do_reconfigure_physical_bridges`, then it triggers 3. `setup_physical_bridges(bridge_mappings)` then it contains 4. br.create() I’m seeing note in code «The bridge already exists, so create won't recreate it», BUT at the same time we’re receiving in logs: ``` Matched CREATE: BridgeCreateEvent(events=('create',), table='Bridge', conditions=None, old_conditions=None) to row=Bridge(name=br-tun ``` and ``` BridgeCreateEvent, bridge name: br-tun ``` Constantly – by hours and for all our bridges (we have four: br-tun, br-ex, br-int, br-rmi) while we will not restart ovs agent. So this event fills idl_monitor.bridges_added then ovs reacting on it by _do_reconfigure_physical_bridges, then it triggers br.create() and we’re receiving event once again – we’re in the loop. Want to add that our datapath-id NOT changing between these runs – keeps same. Additional debugging shows that bridges `_uuid` are not changing in tables, which means that rows were not added => but for some reason, we’re receiving an event about it. Any ideas or ways how to fix this problem and never experience it again?

2 1

[neutron] Bug report 40th week (Sep 30th - Oct 6th)
by Rodolfo Alonso Hernandez 07 Oct '24

07 Oct '24

Hello Neutrinos: This is the bug report of the 40th week (Sep 30th - Oct 6th). High: * https://bugs.launchpad.net/neutron/+bug/2083237: Initial router state is not set correctly. Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/929406. * https://bugs.launchpad.net/neutron/+bug/2083287: test_add_router_interfaces_on_overlapping_subnets_returns_400 failed when retrying router interface removal after API timeout; (pymysql.err.OperationalError) (1205, 'Lock wait timeout exceeded; try restarting transaction') in neutron log. *Not assigned*. * https://bugs.launchpad.net/neutron/+bug/2083482: "neutron-fullstack-with-uwsgi-fips" failing in stable releases (Zed, 2023.1). Assigned. Patches proposed: https://review.opendev.org/q/topic:%22bug/2083482%22. * https://bugs.launchpad.net/neutron/+bug/2083483: [ovn-octavia-provider] [neutron]/endpoint_type is not respected. Assigned. Patch proposed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/931141. * https://bugs.launchpad.net/neutron/+bug/2083609: neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_ha_router_failover_host_failure fails with "MismatchError: 2 != 1: More than one active HA routers". *Not assigned*. * https://bugs.launchpad.net/neutron/+bug/2083682: Slowness of security groups list API. *Not assigned*. Medium: * https://bugs.launchpad.net/neutron/+bug/2083226: [scale] Adding a public external network to a router is killing database. Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/930888. * https://bugs.launchpad.net/neutron/+bug/2083456: Unable to detect from OVN DB if Neutron uses distributed floating IPs or not. Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/931067. * https://bugs.launchpad.net/neutron/+bug/2083570: Neutron times out handling a request to create a network. *Not assigned*. To be discussed/undecided: * https://bugs.launchpad.net/neutron/+bug/2083527: [OVN] dnat_and_snat rules are setting GATEWAY_PORT when LR pinned to chassis. * https://bugs.launchpad.net/neutron/+bug/2083760: API request is not logged when neutron is run by httpd+mod_wsgi. Regards.

1 0

[Openstack] devstack won't startup nova-api
by Maxim Sava 07 Oct '24

07 Oct '24

Hi, During new devstack install get nova-api did not start. I appreciate any help you can provide. # Logs: +:: sleep 1 ++:: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}' http://192.168.122.157/compute/v2.1/ +:: [[ 503 == 503 ]] +:: sleep 1 ++:: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}' http://192.168.122.157/compute/v2.1/ +:: [[ 503 == 503 ]] +:: sleep 1 +functions:wait_for_service:472 rval=124 +functions:wait_for_service:477 time_stop wait_for_service +functions-common:time_stop:2421 local name +functions-common:time_stop:2422 local end_time +functions-common:time_stop:2423 local elapsed_time +functions-common:time_stop:2424 local total +functions-common:time_stop:2425 local start_time +functions-common:time_stop:2427 name=wait_for_service +functions-common:time_stop:2428 start_time=1728285798601 +functions-common:time_stop:2430 [[ -z 1728285798601 ]] ++functions-common:time_stop:2433 date +%s%3N +functions-common:time_stop:2433 end_time=1728285858734 +functions-common:time_stop:2434 elapsed_time=60133 +functions-common:time_stop:2435 total=2287 +functions-common:time_stop:2437 _TIME_START[$name]= +functions-common:time_stop:2438 _TIME_TOTAL[$name]=62420 +functions:wait_for_service:478 return 124 +lib/nova:start_nova_api:1015 die 1015 'nova-api did not start' +functions-common:die:285 local exitcode=0 [Call Trace] ./stack.sh:1299:start_nova_api /opt/stack/devstack/lib/nova:1015:die [ERROR] /opt/stack/devstack/lib/nova:1015 nova-api did not start exit_trap: cleaning up child processes Error on exit # Trying to connect [stack@devstack devstack]$ curl http://192.168.122.157/compute/v2.1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>503 Service Unavailable</title> </head><body> <h1>Service Unavailable</h1> <p>The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.</p> <hr> <address>Apache/2.4.52 (Ubuntu) Server at 192.168.122.157 Port 80</address> </body></html>

2 1

How To Create Snapshot Via Python Module
by Saeed 06 Oct '24

06 Oct '24

Hello everyone, this is my python code to find a specific server: import openstack openstack.enable_logging(debug=False) servers = [] for region in ['region1', 'region2', 'region3']: openstack_connection = openstack.connect(cloud=region) # clouds.yaml for server in openstack_connection.compute.servers(details=True, hostname='my_specific_hostname'): servers.append(server.to_dict()) servers = servers[0]['id'] Now I'm going to create a snapshot from this ID only. How can I do that? I read the documents but was unable to find proper way in Python. Regards, Saeed

1 0

Re: openstack-discuss Digest, Vol 72, Issue 23
by BEDDA Fadhel 06 Oct '24

06 Oct '24

Good morning, I created a debian (12) instance on openstack. But I don't know what the username and password are. Please help m Le ven. 4 oct. 2024 à 19:48, <openstack-discuss-request(a)lists.openstack.org> a écrit : > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > Today's Topics: > > 1. Re: [all][qa][infra] Restore unit tests for intermediate python > versions > (Takashi Kajinami) > 2. Re: [all][qa][infra] Restore unit tests for intermediate python > versions > (Takashi Kajinami) > 3. Re: [cinder] What is the "official" name for Cinder in the service > catalog? > (Ghanshyam Mann) > 4. Re: [cinder] What is the "official" name for Cinder in the service > catalog? > (Takashi Kajinami) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 5 Oct 2024 02:26:59 +0900 > From: Takashi Kajinami <kajinamit(a)oss.nttdata.com> > Subject: Re: [all][qa][infra] Restore unit tests for intermediate > python versions > To: Clark Boylan <cboylan(a)sapwetik.org>, > openstack-discuss(a)lists.openstack.org > Message-ID: <9aec1a2b-0f30-4a47-879f-76ada4412057(a)oss.nttdata.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 10/5/24 01:47, Clark Boylan wrote: > > On Fri, Oct 4, 2024, at 9:30 AM, Takashi Kajinami wrote: > >> Hello, > >> > >> > >> As you may know, current master runs unit tests with only Python 3.9 > >> and Python 3.12. > >> My understanding about this set up is that we test the minimum boundary > >> and the maximum > >> boundary and assume the change may work with all the versions between > >> these two. > >> > >> However in some of my recent work I had to introduce the switch in the > >> middle of these > >> two versions. For example > >> https://review.opendev.org/c/openstack/neutron/+/931271 introduces > >> the logic to distinguish Python < 3.10 from Python >= 3.10 , and we > >> don't specifically > >> test that boundary. I'm afraid that this may potentially cause uncaught > >> problems. > > > > One approach that wasn't discussed in the change is to continue to use > the existing code (pkg_resources) until python3.12 then only change the > behavior for 3.12. That approach would generally work if we are only > testing the boundaries since we're flipping the behavior on the boundary. > > For this case we need python 3.11 job to test the boundary. Also this > leaves > noisy deprecation warnings in < Python 3.11 . > > > > >> > >> So my question here is ... Can we test all supported python versions, > >> not only min/max, > >> at least in check jobs ? This would helps us catch any regressions > >> caused by such > >> implementation. > > > > We can. The main limitation is that we may not have a test platform for > every version of python depending on how the distro releases align with > python releases. Currently I think we have a platform for every release > though (centos/rocky 3.9, jammy 3.10, bookworm 3.11, noble 3.12). If we end > up without a platform for a version of python jobs may need to be updated > to install python from source or some other method. > > acknowledged > > > >> > >> I know there could be tradeoffs between test coverage and infra > >> resources, but IMO > >> this is the test coverage we should fill. > > > > Yes, the main concern was simply to avoid unnecessary effort. In the > case of unittest jobs the vast majority of those are much cheaper in terms > of resources than tempest jobs. I think if we stuck to this primarily for > unittests the impact would be minimal. If we tried to expand the tempest > matrix that would become unwieldy. > > Yes. I don't intend to run all tests in all versions but at least having > unit test jobs, > which are supposed to be cheap, may avoid 0 test coverage and would be > enough now. > > In case we find any real problems then we can expand the scope to other > jobs. > > > > >> > >> Thank you, > >> > >> -- > >> Takashi Kajinami > >> irc: tkajinam > >> github: https://github.com/kajinamit > >> launchpad: https://launchpad.net/~kajinamit > > ------------------------------ > > Message: 2 > Date: Sat, 5 Oct 2024 02:29:31 +0900 > From: Takashi Kajinami <kajinamit(a)oss.nttdata.com> > Subject: Re: [all][qa][infra] Restore unit tests for intermediate > python versions > To: Jeremy Stanley <fungi(a)yuggoth.org>, > openstack-discuss(a)lists.openstack.org > Message-ID: <6b5f06e2-1c2f-4e62-be6f-fb289922bb4d(a)oss.nttdata.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 10/5/24 02:16, Jeremy Stanley wrote: > > On 2024-10-05 01:30:30 +0900 (+0900), Takashi Kajinami wrote: > > [...] > >> to distinguish Python < 3.10 from Python >= 3.10 > > [...] > > > > This is a questionable choice of implementation, given some distros > > in the past have backported features to older releases or reverted > > removals they saw as regressions. When possible, it makes more sense > > to test for the existence/absence of the feature you want to use > > rather than blindly assuming the (C)Python version will serve as a > > faithful proxy. An up-side to this approach is that you don't need > > to worry as much about version boundaries, as long as you test > > versions both with and without the feature/behavior in question. > > The super annoying thing with that change is that > importlib.metadata.entry_point > has been existing since python 3.8 but it changed the behavior in python > 3.10 . > So checking existance of modules/attributes didn't work and I avoided > implementing > hanky inspect check to analyze accepted arguments. > > An alternative solution may be relying on importlib_metadata for all > versions because > it works for Python 3.12, but I was unsure if requiring unnecessary 3rd > party dependency > to make the code older version would be a good choice. > > ------------------------------ > > Message: 3 > Date: Fri, 04 Oct 2024 10:38:36 -0700 > From: Ghanshyam Mann <gmann(a)ghanshyammann.com> > Subject: Re: [cinder] What is the "official" name for Cinder in the > service catalog? > To: "Artem Goncharov" <artem.goncharov(a)gmail.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Message-ID: > <192589cb074.be2d62a51024073.7540045177503817038(a)ghanshyammann.com > > > Content-Type: text/plain; charset="UTF-8" > > ---- On Fri, 04 Oct 2024 10:26:33 -0700 Artem Goncharov wrote --- > > This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli > so no users should be affected unless they explicitly ignored official > rules. > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > On Fri, Oct 4, 2024, 19:23 Artem Goncharov artem.goncharov(a)gmail.com> > wrote: > > Official procedure is described at > https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.… > > You know the service that you want to talk to and there is a list of > service types that the service supports. You follow the procedure to find > the one set by your cloud. > > We have been trying to standardize the use of service catalog type for > many years (I think ~7-8 years :) or maybe more), and > if we still expect/support users to use them the wrong way, then there is > no point in the whole effort on these guidelines. > In the first step, we should fix our implementation in all the > services/tools you mentioned. This is what devstack change > is trying to impose. > > -gmann > > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > On Fri, Oct 4, 2024, 19:19 Takashi Kajinami kajinamit(a)oss.nttdata.com> > wrote: > > > > > > On 10/5/24 02:03, Artem Goncharov wrote: > > > > > > > > > > > > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami kajinamit(a)oss.nttdata.com > kajinamit(a)oss.nttdata.com>> wrote: > > > > > > IMHO changing the default value now is not a good option here. If > we change the default value > > > in tempest, nova, glance (and so on, if exists) it means that > deployment would break during upgrade > > > unless users explicitly set these options to the legacy value or > update keystone endpoints to use > > > the new type. > > > This sounds like a quite breaking change which makes upgrade of > real deployments difficult. > > > > > > May I know if there is any clear downside of using 'volumev3' ? > To be honest based on the fact that > > > "volumev3" has been used as default and mentioned in docs for > very long time, I find it little valuable > > > while it has big use impact. > > > > > > > > > > > > There should be no impact at all as long as keystoneauth lib is used > which implements service/version discovery. > > > If services hard coded service type of cinder without implementing > discovery it is clearly a bug and must be fixed instead of sticking to > keeping bugs forever what we do so often. > > > > I'm not following this. Even if we use keystoneauth, we should know the > service type > > to look up the correct endpoint from the list. Or are you saying that > we can determine > > the endpoint for cinder without service_type field ? > > > > There are number of implementations which hard-code volumev3 or use the > volumev3 as default. > > > > > https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&exclu… > > > > examples: > > > https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard… > > > https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os… > > > https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volum… > > > > We may be need to make these at least configurable. > > > > > > > In addition to that a split between upgrade vs. new install should be > implemented (install docs should explicitly recommend proper usage while > existing installations may stick to their current configuration). Moreover > nothing prevents adding multiple values to the catalog and drop older ones > once all consumers are updated to follow the discovery procedure. > > > > I agree we can add multiple service types and endpoints for the same > service. However my main > > concern is that not all users may be aware of the required steps to > avoid inconsistency caused by > > such change of default behavior. > > > > I can easily imagine that users upgrade their deployment and now their > services require block-storage > > service type without noticing they should create that "new" service > type. > > > > > > > > > > > > > > On 10/5/24 01:50, Ghanshyam Mann wrote: > > > > ---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam Mann > wrote --- > > > > > ---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem Goncharov > wrote --- > > > > > > Hey Stephen > > > > > > > > > > > > On Friday, 4 October 2024 15:15:08 GMT+2 Stephen > Finucane wrote: > > > > > > > o/ > > > > > > > > > > > > > > I've proposed a series of patches to "clean up" the > service catalog that > > > > > > > DevStack creates in a deployment. Currently, DevStack > creates two endpoints > > > > > > > for Cinder: one called 'cinderv3' of type 'volumev3' > and another called > > > > > > > 'cinder' of type 'block-storage'. For example: > > > > > > > > > > > > > > { > > > > > > > "services": > > > > > > > [ > > > > > > > { > > > > > > > "name": "cinderv3", > > > > > > > "description": "Cinder Volume Service > V3", > > > > > > > "id": > "65460706a9864e71926f13042f526aeb", > > > > > > > "type": "volumev3", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb>" > > > > > > > } > > > > > > > }, > > > > > > > { > > > > > > > "name": "cinder", > > > > > > > "description": "Cinder Volume > Service", > > > > > > > "id": > "cd406a0e296d47dca1e481e992851bb2", > > > > > > > "type": "block-storage", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2>" > > > > > > > } > > > > > > > }, > > > > > > > // ... > > > > > > > ], > > > > > > > "links": > > > > > > > { > > > > > > > "next": null, > > > > > > > "self": " > http://10.0.108.50/identity/v3/services > http://10.0.108.50/identity/v3/services>", > > > > > > > "previous": null > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > They both ultimately point to the same API, the > Cinder v3 API, meaning one > > > > > > > of these endpoints is redundant. My assumption was > 'block-storage' was the > > > > > > > correct one, since that's the official service type > [1], and that 'cinder' > > > > > > > was the appropriate name since it mirrors what we use > for other services > > > > > > > (nova, neutron, keystone, glance, ...). However, > tkajinam raised the point > > > > > > > [2] that the Install Guide currently recommends use > of the 'volumev3' type > > > > > > > and that projects like Nova and Glance have an > '[cinder] catalog_info' that > > > > > > > defaults to 'volumev3'. If so, is 'block-storage' > really the official > > > > > > > service type, or is it 'volumev3'. If it is, should > we be changing the > > > > > > > Install Guide and the various config option defaults? > > > > > > > > > > > > > > > > > > > Previously we had volumev2 and volumev3. Those are both > versioned aliases to > > > > > > the block-storage as the official service type name > (that is what structure of > > > > > > the service-types-authority claims). Now there is no > volumev2 and thus the > > > > > > confusion grows. > > > > > > I suggest looking at the rendered json at [2] which > states: > > > > > > ``` > > > > > > "cinder": { > > > > > > "aliases": [ > > > > > > "volumev3", > > > > > > "volumev2", > > > > > > "volume", > > > > > > "block-store" > > > > > > ], > > > > > > "api_reference": " > https://docs.openstack.org/api-ref/block-storage/ > https://docs.openstack.org/api-ref/block-storage/>", > > > > > > "project": "cinder", > > > > > > "service_type": "block-storage" > > > > > > }, > > > > > > ``` > > > > > > > > > > > > Catalog consumption process is in detail described at > [3]. It is insanely > > > > > > complex and confusing but that is what all tools that > look at the service > > > > > > catalog do. > > > > > > > > > > > > Overall: > > > > > > - official and unique service_type of the cinder is > block-storage > > > > > > - volumev3 is an alias pointing to explicit v3 api of > block-storage > > > > > > - there was an "idea" that once a service exposing > multiple API versions (and > > > > > > those are exposed independently with version-suffixed > service types) there is an > > > > > > unversioned one pointing to the "latest" version > (therefore typically you also > > > > > > find `volume` service pointing to the v3 > > > > > > - technically install docs should stop suggesting > registering volumev3 > > > > > > including project_id suffix. This is in detail > addressed by the service catalog > > > > > > consumption procedure and in addition blosk-storage v3 > api has a series of > > > > > > APIs without project_id. Continuing appending > project_id in the service > > > > > > catalog is heavily harmful. > > > > > > - install docs may switch to registering > `block-storage` or `volume` instead > > > > > > of volumev3 and even stop pointing it to the v3 api > explicitly since version > > > > > > discovery is there to figure out all the aspects. > > > > > > > > > > With the API version changing and just to keep backward > compatibility of devstack > > > > > among tooling, we kept modifying the catalog name in this > way and ended up with more > > > > > confusion. > > > > > > > > > > I agree to make the cinder catalogue also consistent with > others and name them only > > > > > 'blosk-storage'. > > > > > > > > > > Tempest still uses 'volumev3' as the default cinder > service catalog, but that is something we > > > > > should change as first: > > > > > > > > > > - > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > > > > > > > > > > Just saw that you already proposed that. thanks ++ > > > > > > > > https://review.opendev.org/c/openstack/tempest/+/930296 > https://review.opendev.org/c/openstack/tempest/+/930296> > > > > > > > > -gmann > > > > > > > > > > > > > > -gmann > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 5 Oct 2024 02:48:13 +0900 > From: Takashi Kajinami <kajinamit(a)oss.nttdata.com> > Subject: Re: [cinder] What is the "official" name for Cinder in the > service catalog? > To: Artem Goncharov <artem.goncharov(a)gmail.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Message-ID: <e3731ee2-6ffb-4827-b03e-a0008625a8b5(a)oss.nttdata.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > OK. Thanks for the explanation. > I then probably misunderstood the impact of the change. It sounds like as > long as we use appropriate SDK > in a proper manner, we can look up the endpoint with official service type > by legacy service type and > vise versa, because of internal translation which I was not aware of. > > If that is true, I agree the change has no impact unless something too > hacky is made in services. > > On 10/5/24 02:26, Artem Goncharov wrote: > > This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli > so no users should be affected unless they explicitly ignored official > rules. > > > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > > > On Fri, Oct 4, 2024, 19:23 Artem Goncharov <artem.goncharov(a)gmail.com > <mailto:artem.goncharov@gmail.com>> wrote: > > > > Official procedure is described at > https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.… > < > https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.… > > > > > > You know the service that you want to talk to and there is a list of > service types that the service supports. You follow the procedure to find > the one set by your cloud. > > > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > > > On Fri, Oct 4, 2024, 19:19 Takashi Kajinami < > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote: > > > > > > > > On 10/5/24 02:03, Artem Goncharov wrote: > > > > > > > > > > > > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami < > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com> <mailto: > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>>> wrote: > > > > > > IMHO changing the default value now is not a good option > here. If we change the default value > > > in tempest, nova, glance (and so on, if exists) it means > that deployment would break during upgrade > > > unless users explicitly set these options to the legacy > value or update keystone endpoints to use > > > the new type. > > > This sounds like a quite breaking change which makes > upgrade of real deployments difficult. > > > > > > May I know if there is any clear downside of using > 'volumev3' ? To be honest based on the fact that > > > "volumev3" has been used as default and mentioned in docs > for very long time, I find it little valuable > > > while it has big use impact. > > > > > > > > > > > > There should be no impact at all as long as keystoneauth lib > is used which implements service/version discovery. > > > If services hard coded service type of cinder without > implementing discovery it is clearly a bug and must be fixed instead of > sticking to keeping bugs forever what we do so often. > > > > I'm not following this. Even if we use keystoneauth, we should > know the service type > > to look up the correct endpoint from the list. Or are you saying > that we can determine > > the endpoint for cinder without service_type field ? > > > > There are number of implementations which hard-code volumev3 or > use the volumev3 as default. > > > > > https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&exclu… > < > https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&exclu… > > > > > > examples: > > > https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard… > < > https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard… > > > > > https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os… > < > https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os… > > > > > https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volum… > < > https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volum… > > > > > > We may be need to make these at least configurable. > > > > > > > In addition to that a split between upgrade vs. new install > should be implemented (install docs should explicitly recommend proper > usage while existing installations may stick to their current > configuration). Moreover nothing prevents adding multiple values to the > catalog and drop older ones once all consumers are updated to follow the > discovery procedure. > > > > I agree we can add multiple service types and endpoints for the > same service. However my main > > concern is that not all users may be aware of the required steps > to avoid inconsistency caused by > > such change of default behavior. > > > > I can easily imagine that users upgrade their deployment and now > their services require block-storage > > service type without noticing they should create that "new" > service type. > > > > > > > > > > > > > > On 10/5/24 01:50, Ghanshyam Mann wrote: > > > > ---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam > Mann wrote --- > > > > > ---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem > Goncharov wrote --- > > > > > > Hey Stephen > > > > > > > > > > > > On Friday, 4 October 2024 15:15:08 GMT+2 > Stephen Finucane wrote: > > > > > > > o/ > > > > > > > > > > > > > > I've proposed a series of patches to "clean > up" the service catalog that > > > > > > > DevStack creates in a deployment. Currently, > DevStack creates two endpoints > > > > > > > for Cinder: one called 'cinderv3' of type > 'volumev3' and another called > > > > > > > 'cinder' of type 'block-storage'. For example: > > > > > > > > > > > > > > { > > > > > > > "services": > > > > > > > [ > > > > > > > { > > > > > > > "name": "cinderv3", > > > > > > > "description": "Cinder Volume > Service V3", > > > > > > > "id": > "65460706a9864e71926f13042f526aeb", > > > > > > > "type": "volumev3", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb < > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb> > <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb > <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb > >>" > > > > > > > } > > > > > > > }, > > > > > > > { > > > > > > > "name": "cinder", > > > > > > > "description": "Cinder Volume > Service", > > > > > > > "id": > "cd406a0e296d47dca1e481e992851bb2", > > > > > > > "type": "block-storage", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 < > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2> > <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 > <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 > >>" > > > > > > > } > > > > > > > }, > > > > > > > // ... > > > > > > > ], > > > > > > > "links": > > > > > > > { > > > > > > > "next": null, > > > > > > > "self": " > http://10.0.108.50/identity/v3/services < > http://10.0.108.50/identity/v3/services> < > http://10.0.108.50/identity/v3/services < > http://10.0.108.50/identity/v3/services>>", > > > > > > > "previous": null > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > They both ultimately point to the same API, > the Cinder v3 API, meaning one > > > > > > > of these endpoints is redundant. My > assumption was 'block-storage' was the > > > > > > > correct one, since that's the official > service type [1], and that 'cinder' > > > > > > > was the appropriate name since it mirrors > what we use for other services > > > > > > > (nova, neutron, keystone, glance, ...). > However, tkajinam raised the point > > > > > > > [2] that the Install Guide currently > recommends use of the 'volumev3' type > > > > > > > and that projects like Nova and Glance have > an '[cinder] catalog_info' that > > > > > > > defaults to 'volumev3'. If so, is > 'block-storage' really the official > > > > > > > service type, or is it 'volumev3'. If it is, > should we be changing the > > > > > > > Install Guide and the various config option > defaults? > > > > > > > > > > > > > > > > > > > Previously we had volumev2 and volumev3. Those > are both versioned aliases to > > > > > > the block-storage as the official service type > name (that is what structure of > > > > > > the service-types-authority claims). Now there > is no volumev2 and thus the > > > > > > confusion grows. > > > > > > I suggest looking at the rendered json at [2] > which states: > > > > > > ``` > > > > > > "cinder": { > > > > > > "aliases": [ > > > > > > "volumev3", > > > > > > "volumev2", > > > > > > "volume", > > > > > > "block-store" > > > > > > ], > > > > > > "api_reference": " > https://docs.openstack.org/api-ref/block-storage/ < > https://docs.openstack.org/api-ref/block-storage/> < > https://docs.openstack.org/api-ref/block-storage/ < > https://docs.openstack.org/api-ref/block-storage/>>", > > > > > > "project": "cinder", > > > > > > "service_type": "block-storage" > > > > > > }, > > > > > > ``` > > > > > > > > > > > > Catalog consumption process is in detail > described at [3]. It is insanely > > > > > > complex and confusing but that is what all > tools that look at the service > > > > > > catalog do. > > > > > > > > > > > > Overall: > > > > > > - official and unique service_type of the > cinder is block-storage > > > > > > - volumev3 is an alias pointing to explicit v3 > api of block-storage > > > > > > - there was an "idea" that once a service > exposing multiple API versions (and > > > > > > those are exposed independently with > version-suffixed service types) there is an > > > > > > unversioned one pointing to the "latest" > version (therefore typically you also > > > > > > find `volume` service pointing to the v3 > > > > > > - technically install docs should stop > suggesting registering volumev3 > > > > > > including project_id suffix. This is in detail > addressed by the service catalog > > > > > > consumption procedure and in addition > blosk-storage v3 api has a series of > > > > > > APIs without project_id. Continuing appending > project_id in the service > > > > > > catalog is heavily harmful. > > > > > > - install docs may switch to registering > `block-storage` or `volume` instead > > > > > > of volumev3 and even stop pointing it to the v3 > api explicitly since version > > > > > > discovery is there to figure out all the > aspects. > > > > > > > > > > With the API version changing and just to keep > backward compatibility of devstack > > > > > among tooling, we kept modifying the catalog name > in this way and ended up with more > > > > > confusion. > > > > > > > > > > I agree to make the cinder catalogue also > consistent with others and name them only > > > > > 'blosk-storage'. > > > > > > > > > > Tempest still uses 'volumev3' as the default > cinder service catalog, but that is something we > > > > > should change as first: > > > > > > > > > > - > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > < > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee…> > < > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > < > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > >> > > > > > > > > Just saw that you already proposed that. thanks ++ > > > > > > > > > https://review.opendev.org/c/openstack/tempest/+/930296 < > https://review.opendev.org/c/openstack/tempest/+/930296> < > https://review.opendev.org/c/openstack/tempest/+/930296 < > https://review.opendev.org/c/openstack/tempest/+/930296>> > > > > > > > > -gmann > > > > > > > > > > > > > > -gmann > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openstack-discuss mailing list -- openstack-discuss(a)lists.openstack.org > To unsubscribe send an email to > openstack-discuss-leave(a)lists.openstack.org > > > ------------------------------ > > End of openstack-discuss Digest, Vol 72, Issue 23 > ************************************************* >

2 1

Re: openstack-discuss Digest, Vol 72, Issue 24
by BEDDA Fadhel 05 Oct '24

05 Oct '24

Good morning, I'm testing openstack (devstack). I downloaded an ubuntu qcow2 image, I created the image from this image, but when I access the console => I find the message: booting form hard disk and nothing happens after Le sam. 5 oct. 2024 à 12:50, <openstack-discuss-request(a)lists.openstack.org> a écrit : > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > Today's Topics: > > 1. Re: [all][qa][infra] Restore unit tests for intermediate python > versions > (Clark Boylan) > 2. Re: Stop bumping major versions when dropping EOL Python versions > (Elõd Illés) > 3. Re: [oslo.messaging] Heartbeat in pthread (Herve Beraud) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 04 Oct 2024 11:22:17 -0700 > From: "Clark Boylan" <cboylan(a)sapwetik.org> > Subject: Re: [all][qa][infra] Restore unit tests for intermediate > python versions > To: "Takashi Kajinami" <kajinamit(a)oss.nttdata.com>, > openstack-discuss(a)lists.openstack.org > Message-ID: <99b5ae0b-2d69-4040-9d3b-8b28491969a6(a)app.fastmail.com> > Content-Type: text/plain > > On Fri, Oct 4, 2024, at 10:26 AM, Takashi Kajinami wrote: > > On 10/5/24 01:47, Clark Boylan wrote: > >> On Fri, Oct 4, 2024, at 9:30 AM, Takashi Kajinami wrote: > >>> Hello, > >>> > >>> > >>> As you may know, current master runs unit tests with only Python 3.9 > >>> and Python 3.12. > >>> My understanding about this set up is that we test the minimum boundary > >>> and the maximum > >>> boundary and assume the change may work with all the versions between > >>> these two. > >>> > >>> However in some of my recent work I had to introduce the switch in the > >>> middle of these > >>> two versions. For example > >>> https://review.opendev.org/c/openstack/neutron/+/931271 introduces > >>> the logic to distinguish Python < 3.10 from Python >= 3.10 , and we > >>> don't specifically > >>> test that boundary. I'm afraid that this may potentially cause uncaught > >>> problems. > >> > >> One approach that wasn't discussed in the change is to continue to use > the existing code (pkg_resources) until python3.12 then only change the > behavior for 3.12. That approach would generally work if we are only > testing the boundaries since we're flipping the behavior on the boundary. > > > > For this case we need python 3.11 job to test the boundary. Also this > leaves > > noisy deprecation warnings in < Python 3.11 . > > The lower bound (currently 3.9) would continue to test the old behavior > (pkg_resources) and the upper bound (python3.12) would test the new > behavior (importlib). It would be covered as well as all of the other upper > and lower bound testing we've done. Python3.10 and 3.11 would be "covered" > by the 3.9 test ensuring that pkg_resources continues to work. When 3.9 is > dropped 3.10 would take over this responsibility. Eventually we'll only > have the importlib behavior and python3.12/3.13/etc would cover it. > > > > >> > >>> > >>> So my question here is ... Can we test all supported python versions, > >>> not only min/max, > >>> at least in check jobs ? This would helps us catch any regressions > >>> caused by such > >>> implementation. > >> > >> We can. The main limitation is that we may not have a test platform for > every version of python depending on how the distro releases align with > python releases. Currently I think we have a platform for every release > though (centos/rocky 3.9, jammy 3.10, bookworm 3.11, noble 3.12). If we end > up without a platform for a version of python jobs may need to be updated > to install python from source or some other method. > > > > acknowledged > >> > >>> > >>> I know there could be tradeoffs between test coverage and infra > >>> resources, but IMO > >>> this is the test coverage we should fill. > >> > >> Yes, the main concern was simply to avoid unnecessary effort. In the > case of unittest jobs the vast majority of those are much cheaper in terms > of resources than tempest jobs. I think if we stuck to this primarily for > unittests the impact would be minimal. If we tried to expand the tempest > matrix that would become unwieldy. > > > > Yes. I don't intend to run all tests in all versions but at least > > having unit test jobs, > > which are supposed to be cheap, may avoid 0 test coverage and would be > > enough now. > > > > In case we find any real problems then we can expand the scope to other > jobs. > > > >> > >>> > >>> Thank you, > >>> > >>> -- > >>> Takashi Kajinami > >>> irc: tkajinam > >>> github: https://github.com/kajinamit > >>> launchpad: https://launchpad.net/~kajinamit > > ------------------------------ > > Message: 2 > Date: Fri, 4 Oct 2024 20:05:02 +0000 > From: Elõd Illés <elod.illes(a)est.tech> > Subject: Re: Stop bumping major versions when dropping EOL Python > versions > To: Jeremy Stanley <fungi(a)yuggoth.org>, > "openstack-discuss(a)lists.openstack.org" > <openstack-discuss(a)lists.openstack.org> > Message-ID: <VI1P18901MB07518D7DBD7CA7D11AF91E18FF722@VI1P18901MB0751 > .EURP189.PROD.OUTLOOK.COM> > Content-Type: text/plain; charset="utf-8" > > Indeed, we started bumping MAJOR version due to dropping py27 support. > Though, the rule is, that a change in required package's version, only > warrants a MINOR version bump. But python is not just a simple dependency, > and dropping support of a python version is more than just bumping any > python package's version. Anyway, if the community wants to stop > bumping major versions in case of dropping python version support, > then i'm probably OK with that. > > Cheers, > Előd > > ________________________________________ > From: Jeremy Stanley > Sent: Monday, September 23, 2024 15:22 > To: openstack-discuss(a)lists.openstack.org > Subject: Re: Stop bumping major versions when dropping EOL Python versions > > > On 2024-09-23 12:25:09 +0100 (+0100), Stephen Finucane wrote: > [...] > > I'd be in favour of getting rid of this particular constraint, and > > instead focusing on API changes when deciding whether to bump the > > major version. Is this a reasonable suggestion, and if so what > > would we need to do to tweak our policy to allow it? > > It makes sense to me. Dropping Python 2.x support was a more > significant event, but these days removing support for minor Python > versions after the corresponding CPython interpreter reaches EOL > upstream is fairly unremarkable. We don't perform major version > increments just for raising the minimum required versions of any > other dependencies, after all. > -- > Jeremy Stanley > > > > ------------------------------ > > Message: 3 > Date: Sat, 5 Oct 2024 12:50:04 +0200 > From: Herve Beraud <hberaud(a)redhat.com> > Subject: Re: [oslo.messaging] Heartbeat in pthread > To: Michel Jouvin <michel.jouvin(a)ijclab.in2p3.fr> > Cc: openstack-discuss(a)lists.openstack.org > Message-ID: > < > CAFDq9gXbkoiRj18zTuqbWAzhg5yhf00JPn6kXh0R83i2CdpyRw(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000008792280623b88de9" > > Voici la version mise à jour avec la solution de **retry backoff** et les > liens supplémentaires : > > Hey folks, > > The major concern behind this thread is that RabbitMQ connection drops due > to the absence of a reliable heartbeat. > While `heartbeat_in_pthread=True` aimed to fix this, it introduced other > bugs. > > Indeed, the Greenlet documentation is pretty clear, the limitations between > Python threads and greenlets lead to issues. > As eventlet is itself based on greenlet it leads to recurring issues in our > stacks. > The heartbeat_in_pthread bugs are living examples of this kind of issue. > > For this reason, we support keeping `heartbeat_in_pthread` disabled by > default. > > As a workaround, adjusting the RabbitMQ `heartbeat_timeout` and > `rabbit_heartbeat_timeout_threshold` can mitigate connection drops. > > Additionally, oslo.messaging offers the `connection_retry_interval` and > `connection_retry_backoff` parameters, > which implement retry backoff strategies to better handle connection drops. > This ensures that the system can manage reconnections more efficiently. > > We encourage investigating these paths to mitigate the connection problems. > > For more details please read: > - https://greenlet.readthedocs.io/en/latest/python_threads.html > - > > https://docs.openstack.org/oslo.messaging/xena/configuration/opts.html#oslo… > - https://www.rabbitmq.com/docs/heartbeats > - > > https://docs.openstack.org/oslo.messaging/xena/configuration/opts.html#oslo… > - > > https://docs.openstack.org/oslo.messaging/xena/configuration/opts.html#oslo… > > > Le jeu. 3 oct. 2024 à 22:46, Michel Jouvin <michel.jouvin(a)ijclab.in2p3.fr> > a écrit : > > > Hi Sean, > > > > Not sure why we misunderstood eachother but we agree! I understood your > > sentence as "people should avoid changing this option from its default > > (False) to True." but I understand now you mean the opposite and I > > totally agree based on our experience. Heat seems to be another service > > that will be in trouble if it is changed. > > > > Michel > > > > Le 02/10/2024 à 14:17, smooney(a)redhat.com a écrit : > > > On Wed, 2024-10-02 at 13:06 +0200, Michel Jouvin wrote: > > >> Hi Sean, > > >> > > >> As for the situation in our cloud after reverting to > > >> heartbeat_in_pthread=false, it was a "black and white situation": > > >> creating a cluster was impossible (because of the Heat issue > mentioned) > > >> since we changed to heartbeat_in_pthread=true (but we didn't realize > > >> immediately as we don't create clusters everyday) and restarted to > work > > >> properly immediately after reverting to heartbeat_in_pthread=false. > > >> There is a clear link between this parameter and Heat behaviour > (Caracal > > >> version in our case, so Oslo client 24.0). > > >> > > >> As for your last sentence "people should avoid cahnging this option > form > > >> tis default fo False.", I think/hope you wanted to say the opposite : > > >> "people should avoid changing this option form its default to > True."... > > > no at least for nova we default to false in our downstream product > > > > > > > > > https://github.com/openstack-k8s-operators/nova-operator/blob/main/template… > > > > > > we had signifcant ci usee when we had it set to true orgianly because > of > > the oslo.log issue > > > but we didn not revert to enabling this for nova-api after that was > > backported because > > > we have not seen any sideefct from seting it to false. > > > > > > we have never set this to true in OSP to my knolage for nova-comptue > > > > > > puppet-nova considered it experimental > > > > > > https://opendev.org/openstack/puppet-nova/src/commit/17bd61e042591305e461e5… > > > > > > in tripleo we disabled it in many services including heat and nova > > > > > > https://github.com/openstack-archive/tripleo-heat-templates/commit/cf4d4f88… > > > > > > in kolla it also default to false for nova-compute and other eventlet > > services > > > > > > https://github.com/openstack/kolla-ansible/blob/2218b7852fda94d0f498d5140f7… > > > although it is enabel for nova-api and some heat compoents > > > > > > https://github.com/openstack/kolla-ansible/blob/2218b7852fda94d0f498d5140f7… > > > > > > https://github.com/openstack/kolla-ansible/blob/2218b7852fda94d0f498d5140f7… > > > > > > at least for nova i would not recommend using > > > > > > heartbeat_in_pthread = True for any serrvice > > > nova-api runnign under uwsgi or mod_wsgi is the only possibel excpetion > > and even then i woudl discurage it. > > > > > > i cant really speak to other services but i think `heartbeat_in_pthread > > = false` is generally the correct default. > > > > > > > > >> Michel > > >> > > >> Le 02/10/2024 à 11:44, smooney(a)redhat.com a écrit : > > >>> On Tue, 2024-10-01 at 22:32 +0200, Michel Jouvin wrote: > > >>>> Hi, > > >>>> > > >>>> I am not an expert in these matters but we recently suffered the > > problem > > >>>> of client deconnection in RabbitMQ due to the heartbeat timeout and > I > > >>>> confirm it was a disaster for the cloud usage with many things not > > >>>> working properly (we are running Antelope, except > Barbican/Heat/Magnum > > >>>> where we run Caracal). The reason is still not clear for me, it was > > >>>> fixed by increasing the heartbeat timeout but at the same time, my > > >>>> colleague who implemented the change also defined > > >>>> heartbeat_in_pthread=true for all the services, something normally > > >>>> unnecessary as we configure uwsgi or Apache to use only one thread > > (and > > >>>> several processes). Initially we didn't see any bad impact of this > > >>>> setting but a few days ago users started to report that Magnum > cluster > > >>>> creation was failing due a "response timeout" in Heat during the > > master > > >>>> software deployment. > > >>>> > > >>>> Reading this thread this morning I had the idea if could be the > source > > >>>> of the problem (as the service was running properly a couple of > weeks > > >>>> ago, before the change). We reverted the change and defined > > >>>> heartbeat_in_pthread=false and it restored the normal behaviour of > > Heat. > > >>>> We have not seen a negative impact on other services so far. So I > > >>>> confirm that setting this parameter to false by default seems a good > > >>>> idea and that setting it to true can break some services like Heat. > > >>> thank you for the data point, im sure you will monitor the situration > > in your > > >>> clodu but please let use know in a week or two if the heat/magnum > > issues you > > >>> obsevered retrun or if the could continue to fucntion normally, > > >>> i expect it to but again it would be a good data point. > > >>>> Cheers, > > >>>> > > >>>> Michel > > >>>> > > >>>> Le 01/10/2024 à 16:31, Arnaud Morin a écrit : > > >>>>> Hey, > > >>>>> > > >>>>> I totally agree about the fact that heartbeat_in_pthread and the > > >>>>> oslo.log PipeMutex are technical debt that we need to get rid of, > > >>>>> as well as eventlet. > > >>>>> > > >>>>> However, despite the fact that it seems purely cosmetic on your > side, > > >>>>> we believe it's not. > > >>>>> I can't prove / reproduce the issue on a small infra, but > definetely, > > >>>>> at large scale, having those tcp connections to be dropped by > > rabbitmq > > >>>>> and recreated in a loop by agents is affecting the cluster. > > >>>>> > > >>>>> I know all the pain that these settings introduced in the past, but > > now > > >>>>> I feel we are in a stable situation regarding this, that's why I am > > >>>>> surprised about deprecating heartbeat_in_pthread now. > > >>> deprecateign a config option requires the deprecation to be > advertised > > in a slrup > > >>> before it can then be removed in a follwoing release. > > >>> Given the deprecation was done in dalmaition 2024.2 which is not a > > slurp release the removal > > >>> cannot take effect in 2025.1, 2025.2 is the earliest release we could > > remove this option. > > >>> > > >>> as a result i think maintaining the deprecation is correct here. > > >>> we may decied not to remove this until 2026.1 or later but i think > its > > correct to send the > > >>> message that people should avoid cahnging this option form tis > default > > fo False. > > >>> we coudl even tag this option as advanced to make that more clear > > >>> > > > https://docs.openstack.org/oslo.config/latest/reference/defining.html#advan… > > >>> > > >>>>> Can we, as least, make sure we keep all of this until we switch off > > >>>>> eventlet? > > >>>>> In other words, can we get rid of eventlet, then remove this > params? > > >>>>> and not the opposite? > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> Arnaud > > > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ >

1 1

[oslo.messaging] Heartbeat in pthread
by Arnaud Morin 05 Oct '24

05 Oct '24

Hello, I completely miss the deprecation of heartbeat_in_pthread in oslo.messaging [1]. We heavily rely on this parameter downstream and our opinion is that it should be set to True by default. We use it for both wsgi services and agents (nova-compute, neutron agents, etc.). I understand that eventlet will be dropped in the future, but should we set heartbeat_in_pthread to True by default until then? Regards, Arnaud. [1] https://review.opendev.org/c/openstack/oslo.messaging/+/925778

5 12

Stop bumping major versions when dropping EOL Python versions
by Stephen Finucane 05 Oct '24

05 Oct '24

o/ Python 3.8 is going EOL (upstream, anyway) next month. We've been working to drop support for this from various SDK deliverables, and I'm guessing (though don't yet know for sure) that this will happen across other project deliverables before long (if it hasn't started happening already). One side-effect of this change is that we will be expected to raise the major version of the affected dependencies on our next release. This is annoying for projects like openstacksdk that use the release-with-intermediary release model because it forces us to have a major version release earlier than we would like to. To give a concrete example, we have a RemovedInSDK50Warning deprecation warning that we are using to indicate (as you might guess) things that we plan to remove in openstacksdk 5.0.0. We need to wait 6 months/1 OpenStack release before removing anything flagged with this warning, so this has been mainly applied to legacy deprecation warnings to put a concrete timeline on their removal. However, because we just dropped Python 3.8 support, it is currently expected that our next release be 5.0.0. We last deprecated something new ~2 months ago, so this means we either cannot release a new version of openstacksdk for 3-4 months (to allow 6 months to pass) or we need to either rename RemovedInSDK50Warning to RemovedInSDK60Warning or add a new RemovedInSDK60Warning and move the offending deprecations to this. None of these are nice options and to be honest, I don't think the major version bump really provides all that much value to end-users: they already have a much better signal for the removal of a Python version in the 'python_requires' marker in setup.py/setup.cfg/pyproject.toml/(other build system file). By using this, we ensure that a user simply can't install a version of a package that doesn't support their chosen Python version. I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it? Cheers, Stephen

4 3

[all][qa][infra] Restore unit tests for intermediate python versions
by Takashi Kajinami 05 Oct '24

05 Oct '24

Hello, As you may know, current master runs unit tests with only Python 3.9 and Python 3.12. My understanding about this set up is that we test the minimum boundary and the maximum boundary and assume the change may work with all the versions between these two. However in some of my recent work I had to introduce the switch in the middle of these two versions. For example https://review.opendev.org/c/openstack/neutron/+/931271 introduces the logic to distinguish Python < 3.10 from Python >= 3.10 , and we don't specifically test that boundary. I'm afraid that this may potentially cause uncaught problems. So my question here is ... Can we test all supported python versions, not only min/max, at least in check jobs ? This would helps us catch any regressions caused by such implementation. I know there could be tradeoffs between test coverage and infra resources, but IMO this is the test coverage we should fill. Thank you, -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 5

[all] Remove 'python_requires' flag from setup.cfg
by Ghanshyam Mann 04 Oct '24

04 Oct '24

Hi All, As you know, we have a flag 'python_requires' in setup.cfg which is pinned to the minimum python version supported[1]. Every time we upgrade our Python testing, we usually bump the minimum python version in setup.cfg and that prevents the project from being installed on lower Python versions. We do have list of tested and supported Python versions in setup.cfg classifier, which is good and enough information to tell what all Python versions are tested[2]. Flag 'python_requires' creates an issue (which has happened many times in the past) when a dependency like oslo lib bumps the version, and it makes all projects testing old Python versions fail. I know we should remove the old Python versions tested from projects first, but somehow, we all are busy, and a coordinated effort is always missed. IMO, we should remove this flag as it creates more issues than benefits. opinion? It will also help to continue users to install things on old python versions if it is working for them. [1] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c8… [2] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c8… -gmann

9 21

[kolla] [cinder-backup] max operations and workers problems
by garcetto 04 Oct '24

04 Oct '24

good morning, using all-in-one ubuntt 22 lts kolla openstack 2024.1 version. cinder.conf " [DEFAULT] ... backup_max_operations = 1 backup_workers = 1 ... " despite this, the cinder-backup container is doing more backups of more istance volumes...why? thank you.

2 3

migrating away from neutron-linuxbridge-agent
by Ionuț Bîru 04 Oct '24

04 Oct '24

Hi, Im running openstack 2023.1 and I intent to move away from linuxbridge agent due to being unmaintained and marked as experimental. Is there a documentation on how to migrate away to neutron-openvswitch-agent ? Is the change straightforward, simple as starting neutron-openvswitch-agent container, stopping/starting the servers from that hypervisor? Do you guys suggest to migrate to ovn instead of openvswitch? --- Ionuț Bîru - Hosterion

2 1

Openstack large deployment with network OVN
by Satish Patel 04 Oct '24

04 Oct '24

Folks, I am planning to deploy the latest openstack with OVN on around 300 compute nodes. based on googling I found there are some best practices for setting to scale OVN with many compute nodes. I would like to get some expert opinion on what is the best option I should go for to deploy OVN. What things should I keep in mind?

1 0

[OSSA-2024-004] OpenStack Ironic: Ironic fails to verify checksums of supplied image_source URLs when configured to convert images to raw for streaming (CVE-2024-47211)
by Jay Faulkner 03 Oct '24

03 Oct '24

==================================================================================================================================== OSSA-2024-004: Ironic fails to verify checksums of supplied image_source URLs when configured to convert images to raw for streaming ==================================================================================================================================== :Date: October 03, 2024 :CVE: CVE-2024-47211 Affects ~~~~~~~ - Ironic: <21.4.4, >=22.0.0 <23.0.3, >=23.1.0 <24.1.3, >=25.0.0, <26.1.0 Description ~~~~~~~~~~~ Julia Kreger of Red Hat noticed a vulnerability in image validation for Ironic, in which images may not have their checksum validated before conversion, potentially permitting man-in-the-middle attacks modifying image data. Patches ~~~~~~~ -https://review.opendev.org/c/openstack/ironic/+/931300 (2023.1/antelope(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931299 (2023.2/bobcat(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931295 (2024.1/caracal(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931294 (2024.2/dalmatian(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931293 (2025.1/epoxy (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931298 (Bugfix/24.0 (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931297 (Bugfix/25.0 (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931296 (Bugfix/26.0 (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931305 (Unmaintained/victoria(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931304 (Unmaintained/wallaby(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931303 (Unmaintained/xena(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931302 (Unmaintained/yoga(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931301 (Unmaintained/zed(ironic)) Credits ~~~~~~~ - Julia Kreger from Red Hat (CVE-2024-47211) References ~~~~~~~~~~ -https://launchpad.net/bugs/2076289 -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-47211 Notes ~~~~~ - No other Ironic-adjacent projects, including Ironic-Python-Agent, require patching to resolve this vulnerability. - As usual, we will provide updated releases off maintained branches, but will not create new releases off bugfix or unmaintained branches. -- Jay Faulkner OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

Live Now! OpenStack 2024.2 'Dalmatian' on OpenInfra Live
by Allison Price 03 Oct '24

03 Oct '24

Hi everyone, Right now, OpenInfra Live is hosting several OpenStack PTLs as well as the chair of the Technical Committee chair from the 2024.2 Dalmatian release cycle to talk about the features from OpenStack’s 30th release. Join us on LinkedIn or YouTube and it’s live, so ask any questions you have for our guests! More information is available at openinfra.dev/live. YouTube: https://www.youtube.com/watch?v=6igJNIJ9yFE LinkedIn: https://www.linkedin.com/events/introducingopenstackdalmatian20724476314826… See you there! Allison

1 0

openstack neutron issue binding VIF
by Stepan Vakheta 03 Oct '24

03 Oct '24

Hello team, I am currently experiencing an issue with the Neutron component, specifically with port binding. I am attempting to use Neutron as an external provider for oVirt networks. I have successfully created the networks and imported them, and oVirt is able to see all the information about the network from Neutron. However, when I create a vNIC in oVirt's VM, it appears in Neutron but it shows that the binding_vif_type is "binding_failed" and the VM does not start. It seems that oVirt is not able to create the port from the imported Neutron Network. Additionally, neither the Neutron controller node nor the Neutron compute node shows any errors according to this case. I have attached the network configuration files of the controller node and the config files of the neutron component. Please let me know if there is anything else I can provide you regarding configs, logs, etc. I appreciate any help you can provide. Regards, Stepan Vakheta

1 0

OpenStack 2024.2 Dalmatian is officially released!
by Elõd Illés 02 Oct '24

02 Oct '24

Hello OpenStack community, The official OpenStack 2024.2 Dalmatian release announcement has been sent out: https://lists.openstack.org/archives/list/openstack-announce@lists.openstac… Thanks to all who were a part of the 2024.2 Dalmatian development cycle! This marks the official opening of the openstack/releases repository for 2025.1 Epoxy releases, and freezes are now lifted. stable/2024.2 is now a fully normal stable branch, and the normal stable policy applies from now on. Thanks, Előd Illés on behalf of the Release Management team

3 2

Kubernetes cluster on top of OpenStack with kops
by Jaime Ibar 02 Oct '24

02 Oct '24

Hi all, anyone is using kops for deploying a kubernetes cluster on top of Openstack? Thanks Jaime -- Jaime

2 1

[all][tc][ptl][ptg] TC Discussions at the PTG - Sign Up and Suggest Topics
by Goutham Pacha Ravi 02 Oct '24

02 Oct '24

Hello Stackers, I'd like to highlight the Technical Committee's PTG planning etherpad [1], where we're organizing our discussions for the upcoming PTG. Over the next week, I aim to finalize time slots and prioritize discussion topics. Since TC discussions are cross-project, we'll do our best to avoid scheduling conflicts with project team meetings. To help with this, I encourage all interested parties to sign up or vote on the topics listed in the etherpad. Feel free to add any additional topics you'd like to discuss as well. Thank you! Best regards, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://etherpad.opendev.org/p/oct2024-ptg-os-tc

1 0

[all] [security] [ptls] Please review core security teams
by Jay Faulkner 02 Oct '24

02 Oct '24

Hi all, I'm writing on behalf of the Vulnerability Management Team (VMT). We often use the ${project}-coresec teams to determine who is best to help triage initial issues. These groups do not appear to be universally up to date. If you are in charge of a repo managed by the VMT ( https://security.openstack.org/repos-overseen.html#repositories-overseen ) please ensure the associated launchpad ${project}-coresec group has active, trusted members of your community -- or otherwise reach out to the VMT in #openstack-security to arrange other contacts if needed. For example, https://launchpad.net/~ironic-coresec/+members contains four longtime Ironic cores and former PTLs. (I'll note: I likely need to audit the equivalent group for Ironic-adjacent repos, and will do that after hitting send). This is extremely important! If we can't get an issue triaged and dealt with in time, it gets opened to the public. If there's any questions, feel free to respond here or reach out in #openstack-security on OFTC. Thanks, Jay Faulkner

1 0

[ironic] Postgres CI job broken
by Julia Kreger 02 Oct '24

02 Oct '24

Greetings folks, We had a little bit of a discussion on this subject in #openstack-ironic IRC earlier today[0], but the tl;dr is it appears the postgres integration CI job Ironic has had as a "canary" of support is now failing. This time it appears to be rooted in keystone[1]. Like our prior times of raising awareness, we're sending this email to the mailing list. Given the overall deprecation of postgres support many years ago, and the decline in postgres CI jobs in OpenStack, we believe it is time for us to remove this CI job. That being said, if someone wants such support to be fixed and rejuvenated, please consider this email your call to action. Thanks, -Julia [0]: https://meetings.opendev.org/irclogs/%23openstack-ironic/%23openstack-ironi… [1]: https://7d12977942ed9fbb75e4-56d2480851ef91de1634aa83a3abd804.ssl.cf1.rackc…

2 1

[Kolla-Ansible] [Ironic] Node Deploy Failed with MissingAuthPlugin
by Ali Hussain 02 Oct '24

02 Oct '24

Hi Kolla and Ironic folks, While playing with stable/kolla release to fix the No VIF found error. Looks like adding Readers role to ironic user fixed it. But run into Missing Auth plugin [2] issue while image is being deployed to ironic node. Openstack endpoint list command [1] shows the correct IP of the controller. My question is: 1. Kolla-Ansible needs explicite Ironic keystone configuration in Ironic.conf? Following this link <https://docs.openstack.org/kolla-ansible/yoga/reference/bare-metal/ironic-g…> which does not seems to need any keystone configurations. This issue is observed when 1. --boot-interface redfish-virtual-media 2. --deploy-interface ramdisk 3. --driver-info deploy_iso= 4. -instance-info kernel & ramdisk 2. My passwords.yaml has 1. ironic_database_password: 2. ironic_inspector_database_password: 3. ironic_inspector_keystone_password: 4. ironic_keystone_password: Any suggestions please. Thank you. Ali [1] openstack endpoint list | grep ironic | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | internal | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | public | http://<IP>:6385 | | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | public | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | internal | http://<IP>:6385 [2] *Error: *Detected change in error condition on node Node1. Deploy step deploy.deploy failed with MissingAuthPlugin: An auth plugin is required to determine endpoint URL.. An unhandled exception was encountered while aborting. More information may be found in the log file.

2 6

Automating Network VLAN Reconfiguration Post-Bare Metal Provisioning with OpenStack Ironic
by Hajasolo 02 Oct '24

02 Oct '24

Hello OpenStack Community, I am currently working with OpenStack Ironic for provisioning bare metal servers and facing a specific challenge related to network security and automation. I would appreciate any insights or experiences you could share! We use Ironic to provision bare metal servers, which involves utilizing a management VLAN during the PXE boot and initial OS installation process. Post-provisioning, the server’s management interface remains accessible, posing a security risk as it can potentially access the management network. I need to ensure that once a server is provisioned and handed over to a user, it cannot access the management VLAN until it is deprovisioned. 1. How can we automate the process of removing the management VLAN from the server’s network interface post-provisioning to prevent unauthorized access to the management network? 2. Upon server deprovisioning, how can we automatically re-enable the management VLAN to allow for server re-provisioning? 3. Are there any built-in OpenStack tools or common practices within the Ironic or larger OpenStack community to handle such scenarios? Our goal is to maintain a high level of automation and self-service capability in our OpenStack environment while ensuring rigorous network security standards. Solutions that integrate seamlessly with OpenStack’s existing architecture would be ideal. Thank you for your time and help! Best regards, Haja, Joel

2 1

[largescale-sig] Next meeting: September 18, 9utc
by Thierry Carrez 01 Oct '24

01 Oct '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240918T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 3

[Glance] Weekly Meeting Cancelled (OCT 3)
by Pranali Deore 01 Oct '24

01 Oct '24

Hi All, As discussed during last week's meeting[1], the meeting for 3rd OCT has been cancelled. See you all next week!! [1]: https://meetings.opendev.org/irclogs/%23openstack-meeting/%23openstack-meet… Thanks, Pranali

1 0