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

Student Opportunity - CMU Summer Semester 2025
by Kendall Nelson 05 May '25

05 May '25

Hello All! Are any of you interested in mentoring students to work on any projects you have on the backlog? This is what I have from one of the Profs of the course: ------- To remind you of the ask from last year (and *call out differences for this year*): - We are looking for projects that a team of 4-5 students could tackle together with at least two mentors for each project. As we saw last year, mentors can certainly overlap projects if appropriate and they have the time. (Life happens and having the built-in mentor redundancy helps. I’ve had mentors get laid off, change jobs, and take summer vacation.) - Mentors are expected to meet student teams once a week for an hour (via any video conference setup folks want to use), and to be available by email during the rest of the week to answer any urgent questions. - *This summer we are running the class from 13 May to 31 July (11 weeks)*. - *We want to try teaching concurrently in both campuses Doha, Qatar (GMT+3) and Pittsburgh (GMT-5), USA. The entire course will be taught virtually this year, without a classroom.* I certainly did something similar a few years ago when I was teaching at Hopkins (20 students) with another group in Galway (16 students). The morning class in Pitt will be the afternoon in Doha. - *We likely have 15-20 students in each location, so if you had on the order of 4-5 team projects with mentors that fit the format, like last year, that would be fantastic. * - *We are considering going so far as to choose the teams across time zones to get them working remotely from the start.* Last year, after six weeks together in class and daily stand-ups, the students scattered home away from Doha, and all of them worked remotely the last four weeks. They proved they could work remotely together. Of course, the relationships with mentors have always been remote. The profs in Doha and Pitt want to try remote from the beginning. (I have a few concerns but I’m also always up to experiment on students.) - We post the projects on the first day of class and will organize the teams in that first couple of days, so student teams are introduced to their mentors in the first week of class and expected to organize that first meeting to begin the project learning curve. That’s when mentors point students at any tutorials and bootstrap materials, recommended getting started materials, etc. - We have set the expectations with the students that they will be spending 20-40 hours of time per week on the project. It is an internship-like experience. - *Two co-teachers run classes on three days a week for 50 minutes, and I will guest lecture a collection of classes. *(Last year, there was just the real professor and I.) - The three of us will provide a coaching session with each team to ensure they are working with the mentors well. - Students generally have Windows or Mac laptops, but we have teaching assistants on each site that we can start to prep any other access to resources they might need. - As with last year, mentors have a lot of freedom to experiment. Some have run joint sessions if they are mentoring more students for learning curves. Some have run Slack or Discord channels. ------ So, who is interested in working with students? Please let me know if you have any additional questions. -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 1

[barbican] Weekly meeting canceled 5-5-2025
by Grzegorz Grasza 05 May '25

05 May '25

Hi all, Due to conflicts and time off, we have to cancel the Barbican weekly meeting today (5-5-2025). Please reach out via IRC if you need anything. Thanks! / Greg

1 0

[kolla][OpenStackAnsible] 2025.1 Epoxy release for cycle-trailing projects
by Elõd Illés 05 May '25

05 May '25

Hi teams, This is a gentle reminder that the following projects with cycle trailing release model haven't done their 2025.1 Epoxy release yet: [kolla] ansible-collection-kolla kayobe kolla-ansible kolla [OpenStackAnsible] openstack-ansible-roles openstack-ansible Note, that next week we'll ask for cutting stable/2025.1 branches, as kind of a Feature Freeze, 3 weeks prior the 2025.1 Epoxy Cycle-Trailing Release Deadline on June 5th, 2025 [1] (exactly one month away). [1] https://releases.openstack.org/flamingo/schedule.html#f-cycle-trail Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

1 0

[tacker] Skip next IRC meeting
by Yasufumi Ogawa 05 May '25

05 May '25

Hi Tacker team, Due to a holiday in Japan and most of us will not join, I would like to skip IRC meeting tomorrow. Thanks, Yasufumi

1 0

[manila] Share Encryption Collab Review meeting on 2025-05-08
by Goutham Pacha Ravi 03 May '25

03 May '25

Hello Zorillas and interested stackers, We're hosting a discussion on meetpad during the weekly Manila Team meeting slot [1][2] next week, 2025-05-08 (Thursday) to further discuss the design of share encryption. The discussion will follow a proposed specification [3], and seeks to align a number of folks that are implementing the API/UX portions, back end storage driver pieces and functional tests. The meetpad discussion will be at 15:30 UTC. We'll have our weekly IRC meeting as usual at 1500 UTC. Thanks, and hope to see you there, Goutham Pacha Ravi (gouthamr) [1] Manila Team Meeting: https://meetings.opendev.org/#Manila_Team_Meeting [2] ICS for this collab review: https://gist.github.com/gouthampacha/0eaaad7bb2eec343dd56cf15f2f87f9a [3] Design Spec for share encryption:

1 0

OVN Routers don't seem to be highly available
by Ryan Belgrave 03 May '25

03 May '25

I have Openstack dalmatian deployed with OVN. All networking seems to work as expected, however OVN routers don't seem to be highly available. I've followed this guide https://docs.openstack.org/neutron/latest/install/ovn/manual_install.html and have enable-chassis-as-gw set on all the compute nodes. I have a very simple network setup with 1 self-service network connected to a router and that router connected to a provider network. Looking in the OVN SB database at the port_binding for the router, it has 1 chassis listed and a ha_chassis_group. There are multiple compute nodes listed in the ha_chassis_group when I lookup that ID in the table. When I fail the server that is listed as the chassis for the port binding it never gets assigned to a different chassis and the instances in the self-service network stop being able to connect to things in the provider network. I've tried various different ways to fail the server, unplugging the self-service nic makes the port_binding chassis show as "[]" and it never gets assigned to another, hard powering off the server keeps the chassis as the old one and it never gets assigned to another. Waiting multiple minutes to 1+ it never gets reassigned. As soon as I bring back the failed compute node, it gets assigned back to that one and everything works. The only way I can seem to get a failover to another compute node is to stop the ovn-controller service on the server that is listed as the chassis for the port binding. In that case another chassis does get assigned and routing works as expected. According to https://docs.openstack.org/neutron/latest/admin/ovn/routing.html under Failover (detected by BFD) this should "just work". I did check the tunnels and BFD status and BFD does show as down as expected, but nothing else happens. Any ideas? I'm not too sure what to look at to debug this, all my configs seem fine as everything else works as expected.

2 2

[cinder][nova][rbd]instance cannot boot when using qos
by Nguyễn Hữu Khôi 02 May '25

02 May '25

Hello. I create a volume type with qos which uses frontend consumer then I create an instance which booted from a volume, however, It stucked it booting from hardisk. What could will be? Pls give me some ideas on this? Thank you. Env: Openstack 2025.1 KollaAnsible 2025.1 master Ubuntu 2024.02 Nguyen Huu Khoi

3 7

[manila] Removal of the Standalone CephFS NFS protocol helper in Epoxy
by Ashley Rodriguez 02 May '25

02 May '25

Hi zorillas! As per subject line, we will be deprecating the standalone CephFS NFS protocol helper in this cycle. This is following our deprecation warning we put out in 2024.1 / Caracal [1] [2]. We've supported using a clustered Ceph NFS service since the Zed release. We've also added upgrade helpers to migrate from a standalone NFS-Ganesha service to the ceph-orch-deployed clustered NFS service; this code was backported to stable/2023.1 (Antelope). Although the upgrade path is disruptive, there is a UX improvement in Manila to ease this migration through surfacing “preferred” export paths. Moving forward, deployments must have “cephfs_nfs_cluster_id” in your configuration, otherwise the driver will fail to start. Manila will not make any export changes to NFS-Ganesha, so upgrading manila without an NFS cluster will mean that only the control plane is not going to work; but, data plane will remain unaffected. To assist migration, admins can also configure "cephfs_ganesha_export_ips" (or alternatively, "cephfs_ganesha_server_ip") alongside "cephfs_nfs_cluster_id". Setting these options will allow the CephFS driver to report additional export paths. These additional export paths will have the "preferred" metadata key set to False. Best, Manila team [1] https://review.opendev.org/c/openstack/manila/+/912648 [2] https://docs.openstack.org/manila/2024.2/configuration/shared-file-systems/…

5 7

RDO Epoxy 2025.1 Release - Important Note at Bottom
by Amy Marrich 01 May '25

01 May '25

RDO Epoxy 2025.1 Release - Important Note at Bottom The RDO community is pleased to announce the general availability of RDO builds for OpenStack 2025.1 Epoxy for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public and hybrid clouds. Epoxy is the 31st release of the OpenStack project, backed by over 1,000 contributors worldwide. This release is already available on CentOS Stream 9 on the CentOS mirror network: https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ The RDO community project curates, packages, builds, tests, and maintains a complete set of OpenStack components 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 on-premise, public, or hybrid clouds. All work on RDO and its downstream release, Red Hat OpenStack Services on OpenShift, is 100% open source, with all code changes going into it's related upstream first. You can read the broader upstream OpenStack project highlights at https://releases.openstack.org/epoxy/highlights.html, but here are some highlights: - Notably, active/active support for Dell PowerStore, Dell PowerStore QoS support, NetApp adding support for active/active mode in ISCSI/FC drivers, HPE Nimble replication, and StorPool adding support for pool-to-pool cloning. - To address OSSN-0090 and OSSN-0065, support was added for a new add/get location API that replaces the image update (old location-add) mechanism for consumers such as cinder and nova. - Ironic includes multiple security improvements: - All supported mechanism drivers (ML2/OVS, ML2/OVN) can now use the WSGI API module, and the first phase of deprecation of the eventlet library is complete. - Instances with UEFI can now boot in stateless pending if the image has the hw_firmware_statelessproperty and the compute service has libvirt 8.6.0 or later. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) upgrades will only be supported from the Caracal 2024.1 release to the next SLURP release (phase Epoxy). RDO Epoxy 202 5.1 has been published by the CentOS Storage SIG in the official CentOS repository and has been built and tested with the latest released Ceph 18.2.0 Reef version ( https://docs.ceph.com/en/latest/releases/reef/) *Note:* Follow the instructions in the [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services on the same host. During Epoxy cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Epoxy 2025.1 release: - python-saharaclient (https://review.rdoproject.org/r/c/rdoinfo/+/54360) - puppet-corosync (https://review.rdoproject.org/r/c/rdoinfo/+/53127) - python-oauth2client (dependency https://review.rdoproject.org/r/c/rdoinfo/+/54115) During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: - During the Epoxy cycle, we saw the following new RDO contributors: - Ashish Gupta - Dmitriy Chubinidze - Francisco Seruca Salgado - Ivan Anfimov - Lilach Avraham - Manoj Katari - Saurabh Agarwal - Sofer Athlan-Guyot - Viji Candappa 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: - Alan Pevec - Alfredo Moralejo - Amy Marrich - Ananya Banerjee - Artom Lifshitz - Ashish Gupta - Bogdan Dobrelya - Chandan Kumar - Daniel Pawlik - Dmitriy Chubinidze - Douglas Viroel - Eduardo Olivares - Fiorella Yanac - Francesco Pantano - Francisco Seruca Salgado - Harald Jensås - Ivan Anfimov - Jakub Libosvar - Jaromír Wysoglad - Joan Francesc Gilabert - Joel Capitao - Karolina Kula - Lewis Denny - Lilach Avraham - Luigi Toscano - Manoj Katari - Maor Blaustein - Martin Kopec - Matthias Runge - Matthieu Huin - Miguel Garcia - Mikołaj Ciecierski - Pablo Rodríguez Nava - Pooja Jadhav - Rabi Mishra - Radomir Dopieralsk - iRodolfo Alonso - Ronelle Landy - Saurabh Agarwal - Sergii Golovatiuk - Shreshtha Joshi - Sławek Kapłoński - Sofer Athlan-Guyot - Takashi Kajinami - Tobias Urdin - Tony Breeds - Viji Candappa - 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. Join us in #rdo and on the OFTC IRC network. You can also find us on Facebook and YouTube. *Important Note!* We had a thriving, if small, group of community members maintaining packages prior to COVID and we need to return to those days of having folks participate in this effort. The OpenStack RPM packaging effort is in need of package maintainers in order to continue having RPMs. The current maintainers have moved on to new opportunities, so while we have folks continuing to contribute, we currently have no folks to build and maintain packages. Please check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Please reach out if you can help!

1 0

[neutron][ovn] both vxlan and geneve cannot get full bandwidth
by Nguyễn Hữu Khôi 01 May '25

01 May '25

Hello. I am going with ovn for my system but when I use vxlan and geneve, my instance cannot get full bandwidth(12 gbps)-instance to instance with private network. It is ok if I use vlan or floating ip for instances. My env: Openstack 2025.1 Kolla Ansible master-2025.1 Ubuntu 22.04 with uplink 25gbps x 2 for bonding, lacp 802.3ad, layer3+4 Ps give me some points. Thank Nguyen Huu Khoi

4 8