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

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