- openstack-discuss - lists.openstack.org

[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 04 May '25

04 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 02 May '25

02 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 02 May '25

02 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 01 May '25

01 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 30 Apr '25

30 Apr '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

[all][rbac] Changing policy popup team meeting schedule
by Ghanshyam Maan 30 Apr '25

30 Apr '25

Hello Everyone, As discussion topics are less during biweekly meetings (most of the time it's just me), I am updating the RBAC policy pop-up meeting to occur monthly on the first Monday of each month. The next meeting will be on May 5th. NOTE: We still have many projects to complete the RBAC goal, and you do not need to wait for the meeting to ask RBAC-related help/queries, feel free to reach out to me on IRC/ML. - https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… - https://review.opendev.org/c/opendev/irc-meetings/+/948569 -gmann

1 0

[Neurton][OVN] Not able to remove geneve tunnel
by keerthivassan86＠gmail.com 30 Apr '25

30 Apr '25

As part of openstack-ansible deployment, removed geneve tunnel config as you mentioned, now we have only below on neutron server [ml2] type_drivers = vlan tenant_network_types = vlan mechanism_drivers = ovn Same config for neutron in compute node as well, under ovn external_id external_ids : {hostname=xxxx ovn-bridge-mappings="vlan:br-ex", ovn-cms-options="availability-zones=nova", ovn-remote="tcp:xxxx:6642,tcp:xxxxx:6642", rundir="/var/run/openvswitch", system-id="01a70eda-59bb-4e8b-870d-08eba09abae3"} With above config, we do see below error in ovn-controller & not able to connect to SB DB ovn-controller.log: 2025-04-29T17:38:48.508Z|00012|main|INFO|OVN internal version is : [24.03.2-20.33.0-72.6] 2025-04-29T17:38:55.206Z|00026|chassis|INFO|Need to specify an encap type and ip 2025-04-29T17:38:55.206Z|00027|chassis|INFO|Need to specify an encap type and ip 2025-04-29T17:38:55.206Z|00028|chassis|INFO|Need to specify an encap type and ip can you please share your inputs on this ? Ideally we don't want to have ovn-*** ports to be created

2 3

[Glance] No meeting on May, 1st
by Cyril Roelandt 30 Apr '25

30 Apr '25

Hello, Thursday is International Workers' Day and most of the Glance team will be away from keyboard. The meeting will therefore be cancelled. Happy Hacking anyway! Cyril Roelandt

1 0

[keystone] Weekly meeting canceled 30-Apr-2025
by Dave Wilde 30 Apr '25

30 Apr '25

Greetings, Due to conflicts and travels we have to cancel this Keystone weekly meeting for this week (30-Apr-2025). Please reach out via the mailing list or IRC if you need anything from us. Thank you! /Dave

1 0

[Docs][I18n] Re: Deployment Guide translation of OSA
by Ian Y. Choi 29 Apr '25

29 Apr '25

(Adding: openstack-discuss(a)lists.openstack.org and openstack-i18n(a)lists.openstack.org) Hi, Thank you for reaching out. I've noticed that the "deploy-guide" is not located in the /doc/source folder of the repository. This suggests that there may currently be no direct support from the OpenStack Docs team (now under the TC) or the I18n SIG for this documentation. To align with the Project Team Integration (PTI) structure, I recommend discussing with the core team members of the repository about reorganizing the documentation accordingly. For your reference, I am sharing some additional documents below like [2] - [4], which I hope will help clarify the process and requirements. If you have further questions or need support from the I18n SIG, please feel free to reach out via the openstack-i18n mailing list or the #openstack-i18n IRC channel. This ensures that your queries are visible to all community members and can be addressed more efficiently, rather than contacting me directly. Thank you, /Ian [1] https://docs.openstack.org/doc-contrib-guide/team-structure.html [2] https://docs.openstack.org/i18n/latest/infra.html [3] https://docs.openstack.org/doc-contrib-guide/project-guides.html [4] https://governance.openstack.org/tc/reference/project-testing-interface.html On Tue, Apr 29, 2025 at 12:09 AM Dmitry <dcu995(a)gmail.com> wrote: > Hello, Ian. > > We are currently working on adding the OpenStack-Ansible deployment guide ( > https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/) to > translation server. However, we've encountered a challenge: we are not sure > how to start a job to gather the documents and upload them to Zanata ( > https://review.opendev.org/c/openstack/openstack-ansible/+/947634) > > Could you please guide us on what steps we should take to initiate this > process? > > Thank you very much. >

2 1

Bitergia dashboard outage due to maintenance
by Ildiko Vancsa 29 Apr '25

29 Apr '25

Hi OpenStack community, I’m reaching out to let you know that the OpenStack Bitergia metrics dashboard[1] will be unavailable for a short period of time due to scheduled maintenance, where the underlying OpenSearch cluster will be updated. Details of the downtime: * Start Date: Monday, April 28th at 9:00 AM CEST (12:00 AM PDT) * End Date: Tuesday, April 29th at 4:00 PM CEST (7:00 AM PDT) __During this maintenance window, the dashboard will be inaccessible. Please also note that data updates will not resume until Wednesday.__ Thank you for your understanding. Best Regards, Ildikó [1] https://openstack.biterg.io/app/dashboards#/view/Overview

1 1

[glance] Manually creating an image
by Francesco Di Nucci 29 Apr '25

29 Apr '25

Hi all, I am experimenting with manual creation of images, so I am trying to update the documentation example about a CentOS Stream image creation (https://review.opendev.org/c/openstack/openstack-manuals/+/928128) Is there anyone that could review the steps I wrote? It seems to work but I think there is room for improvement/more best practices to be followed Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

1 0

[kolla-ansible][rabbitmq] Change to quorum queue
by Winicius Allan 29 Apr '25

29 Apr '25

Hi community o/ I've got a little confused about the procedure[1] to change the type of queues to quorum queues. The documentation says that it is needed to stop the services that use Rabbit, but in some tasks in `genconfig` step, some APIs must be up, for example, in[2]. I think the documentation is not too clear, or I just missed something. So, I need to stop services and turn on the APIs? Will it affect the procedure of changing the queue type from classic to quorum? Another question is: when upgrading from Antelope to Caracal, is this procedure mandatory? [1] https://docs.openstack.org/kolla-ansible/latest/reference/message-queues/ra… [2] https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/octavi…

2 2

[neutron] Bug Deputy Report Apr 21 - Apr 27
by Yatin Karel 29 Apr '25

29 Apr '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ==== - https://bugs.launchpad.net/neutron/+bug/2109592 - [master][periodic] oslo master jobs broken with ImportError: cannot import name 'format_inspector' from 'oslo_utils.imageutils' Unassigned - https://bugs.launchpad.net/neutron/+bug/2109591 - master periodic job running with centos 9-stream broken with py39 constraint drop https://review.opendev.org/c/openstack/requirements/+/948285 Unassigned - https://bugs.launchpad.net/neutron/+bug/2109456 - AttributeError occurs when querying ports immediately after starting neutron-server Assigned to Gwangseok Jeon - https://bugs.launchpad.net/neutron/+bug/2107925 - [ovn] neutron_pg_drop deleted when using network log Assigned to Elvira García Ruiz - https://bugs.launchpad.net/neutron/+bug/2109326 - test_release_for_ipv6_lease_no_dhcp_release6 unit tests fails randomly Assigned to Yatin Karel Medium ====== - https://bugs.launchpad.net/neutron/+bug/2109354 - Incorrect behavior when filtering networks by provider:network_type with a limit parameter Unassigned Wishlist ======== - https://bugs.launchpad.net/neutron/+bug/2108952 - [RFE][ml2][ovs] distributed DHCP extends supports for DPU baremetal Unassigned Incomplete ========= - https://bugs.launchpad.net/neutron/+bug/2108985 - [BGP DVR] Incorrect /32 Fixed IP Route Advertisement Logic Asked for more input -- Thanks and Regards Yatin Karel

1 1

[tacker] Skip next IRC meeting
by Yasufumi Ogawa 28 Apr '25

28 Apr '25

Hi team, Due to holidays in Japan this week, I would like to skip today's IRC meeting. Thanks, Yasufumi

1 0

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

28 Apr '25

Hello Stackers, We're a couple of weeks away from milestone-1 of the 2025.2 ("Flamingo") release cycle [1]. A few project teams have added team-specific deadlines to the release schedule. If you're thinking about team-specific events, please propose a change to the "openstack/releases" repository with the details, e.g., like the Nova team is doing [2]. We're looking for volunteers to serve as election officials [3] for the next combined elections for the OpenStack Technical Committee and Project Team Leads. This election will be held between August and September 2025 and will allow us to elect 2026.1's project team leads across the community, alongside 4 TC members. If you're interested, please reach out to me off-list or chime in within the #openstack-election IRC channel on OFTC. In the last week, the TC approved the deprecation of "openstack-ansible-tests". The project team has been working hard to replace all their testing with molecule-based testing that will significantly improve CI jobs. The TC is working on a resolution to amend the Vulnerability Management Team's purview [4] and will follow that up by working with project teams to ensure a streamlined security process. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held over IRC in OFTC's #openstack-tc channel on 2025-04-22 [5]. The meeting was well attended, and we discussed several action items from the Flamingo PTG that was held earlier this month. Some of these concerned the i18n SIG. We briefly discussed how one could obtain visitor statistics that might inform how the documentation websites were being accessed from around the world. We don't publish this information on any website, and we were not keen on involving proprietary, third-party tools to track and report this data. The "goaccess" data is published in Zuul with a short retention (~6 weeks) and may yet answer some questions. A word of warning was shared that the statistics may be influenced by bots and LLM crawlers of late. You may be aware that the SIG has been migrating translation infrastructure from Zanata to Weblate. We recalled the work that happened to set up a hosted Weblate service a few years ago and took action items to follow up offline to investigate changes that are now required. Finally, we intend to follow up on discussions that didn't find room at the PTG in future weekly meetings. The next weekly meeting of the OpenStack TC is today, 2025-04-29. It will be hosted over IRC in OFTC's #openstack-tc channel. This meeting is open to any community member to propose governance discussions. Please find the agenda on the meeting's wiki page [6]. I hope you'll be able to join us! === Governance Proposals === ==== Merged ==== - Fix gmaan's email address | https://review.opendev.org/c/openstack/governance/+/948342 - Deprecate openstack-ansible-tests repo | https://review.opendev.org/c/openstack/governance/+/947622 ==== Open for Review ==== - Updating Ghanshyam email/irc name | https://review.opendev.org/c/openstack/governance/+/948354 - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 - Add openstack/grian-ui | https://review.opendev.org/c/openstack/governance/+/948252 - Retire openstack-helm-infra repo | https://review.opendev.org/c/openstack/governance/+/947611 - Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 === Upcoming Events === - 2025-04-29: StackConf https://stackconf.eu/ - 2025-04-29: SCS Hackathon / OpenStack Birthday: https://events.sovereigncloudstack.org/hackathon5-2025/ - 2025-05-13: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-05-22: OpenInfra UG Meetup, Sweden: https://www.meetup.com/openinfra-user-group-sweden/events/306139678/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] Add Nova deadlines to the official schedule | https://review.opendev.org/c/openstack/releases/+/948077 [3] OpenStack election officials: https://governance.openstack.org/election/#election-officials [4] Extend scope of VMT to cover all project teams: https://review.opendev.org/c/openstack/governance/+/944817 [5] TC Meeting IRC Log 2025-04-22: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-22-17.01.log.html [6] TC Meeting Agenda, 2025-04-29: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Request to Join as GSoC 2025 Mentor for OpenStack
by anjali 28 Apr '25

28 Apr '25

Hi OpenInfra GSoC Team, I’m Anjali Dhanuka, currently working as MTS at Salesforce with backend and cloud engineering experience (JavaScript, AWS, distributed systems). I am very interested in joining OpenStack as a mentor for GSoC 2025. I have prior experience building scalable cloud systems and I am passionate about helping students grow their skills through real-world backend projects. I would love to assist in proposal reviews and mentoring one or more students this summer. Please let me know the next steps or any information you need from me. Looking forward to contributing to OpenInfra’s GSoC journey! Thanks and Regards, Anjali Dhanuka

1 0

[nova] Did something change about interface detach/attach from Yoga to Caracal?
by Nell Jerram 28 Apr '25

28 Apr '25

I'm not sure why it was originally written, but I have an ancient system test that: - creates a VM attached to one network - finds the VM's port and calls interface_detach for it - checks that the VM is now unpingable - calls interface_attach with the relevant network_id - hard reboots the VM - checks that the VM is now pingable again. With Yoga, the test passes, and at the end of the test the VM has one NIC, eth0, with an IP address. With Caracal, the test also passes, but at the end of the test the VM has two NICs: - eth0 with no IP address - eth1 with an IP address. Diffing the Nova code, it looks like interface_detach and interface_attach might actually have been no-ops in Yoga - although possibly only for a "vdpa" vnic-type, and I'm unsure whether that vnic-type would be relevant to my test setup. Any ideas about this? Many thanks - Nell

2 3

[openstack-ansible] lxc-container upgrade from ubuntu 18 to ubuntu 20 for USSURI
by Danish Khan 27 Apr '25

27 Apr '25

Dear Team, I am trying to upgrade lxc-container from ubuntu 18 to ubuntu 20 and I doing it by destroying and recreating lxc-containers. I have successfully upgraded cinder, glance, heat, horizon,memcached, neutron, nova and placement containers. But now I am unable to create galera, utility containers. I am getting below error for both: failed: [host5_galera_container-ac20] (item={'url': ' http://repo.vexxhost.net/mariadb/key.gpg'}) => {"ansible_loop_var": "key", "attempts": 5, "changed": false, "key": {"url": " http://repo.vexxhost.net/mariadb/key.gpg"}, "msg": "Failed to download key at http://repo.vexxhost.net/mariadb/key.gpg: HTTP Error 404: Not Found"} And it seems the URL http://repo.vexxhost.net/mariadb/key.gpg doesn't exist now. Do we have any workaround for this? Regards, Danish

2 5

[neutron] Today's CI meeting cancelled
by Yatin Karel 27 Apr '25

27 Apr '25

Hello Neotron Team !! I will not be around today so cancelling CI meeting. Sorry for the last minute change. -- Thanks and Regards Yatin Karel

1 0

[neutron][ptg] 2025.2 Flamingo PTG summary
by Brian Haley 24 Apr '25

24 Apr '25

Hi all, Thanks for all that attended the meetings, we had a good turnout for Neutron, the Nova/Cinder cross-project and the eventlet removal discussions that were important to the team. For complete notes see the etherpad [0] but a summary is below. And please comment if you feel I missed anything. Thank you, -Brian ### Epoxy retrospective ### Like any other PTG, it started with a retrospective of the past cycle, with the highlights and improvement points. Good: - Eventlet removal is going well. Even the transition period (for the Neutron API with ML2/OVN) finished with good results. - Permanent "open doors" status to welcome newcomers. Our meetings (team meeting, drivers meeting) are a good forum for them. - Removed experimental code (Linuxbridge, IPv6 PD). - Migration from ML2/Linux Bridge to ML2/OVN discussions have started in Operators community (https://etherpad.opendev.org/p/neutron-lb-ovn-migration) Bad: - The loss of 2 important core developers. - No new specs merged in Epoxy cycle. ### Gate Stability ### Team has been very good at addressing gate issues quickly, and meets on a regular basis. We have noticed a few issues related to eventlet changes and are reverting them until we can address them. ### Spring cleanup / Code base modernization ### At the beginning of every cycle, we always try and cleanup the code base, for example, removing deprecated and dead code, doc updates, job consolidation. We have made progress on those already. - During Epoxy, several changes were made to match the expected output of pyupgrade/autopep8 for py39+. We will make a similar change in Flamingo for py310+ as that is now the lower bounds (haleyb). - It was also discussed to include "ruff" to our checklist (mlavalle). - Now that the OVN agent is in place and the default in gate, it was discussed about removing the OVN metadata agent as it is unnecessary to have both. - CI job reduction: move the ML2/OVS iptables-hybrid jobs to periodic (and experimental) and determine if iptables-hybrid driver can be moved to experimental config space. - TODOs: spend some time addressing the current TODO notes in the code, fixing what is proposed, already started. - Remove the unneeded OVN maintenance tasks, according to the comments in the methods. - Will make sure beginning/end of cycle docs are up-to-date on things like CI jobs, etc. (haleyb) ### Eventlet removal ### The "oslo.service" library will implement two backends (eventlet or threading), that will allow us to test both implementations during the removal. It could be useful to have temporary CI jobs, using both implementations. The testing CI (unit test, functional and fullstack) should start the migration during this cycle, but only once the Neutron service code is migrated. Please see [1] and [2] for more information and meetings notes from the eventlet-specific agenda. ### Migration to SDK (neutronclient removal) ### Etherpad link: https://etherpad.opendev.org/p/python-neutronclient_deprecation During the last cycle a number of Horizon patches merged (thanks Lajos!). Heat patches are still under review (and not attended). Nova patch is WIP: https://review.opendev.org/c/openstack/nova/+/928022 Neutron team will add deprecation warnings in the neutronclient code as there are still a number of places in both in and out-of tree code that is using the neutronclient. The fullstack tests will migrate to SDK during this cycle. ### Migrate the OVN L3 scheduler to use HA_Chassis_Group ### Link: https://bugs.launchpad.net/neutron/+bug/2092271 As recommended by the OVN core team, the usage of ``Gateway_Chassis`` to bind a ``Logical_Router_Port`` is deprecated. Instead of this, ``HA_Chassis_Group`` should be used. This bug tracks this effort that should be done during the next cycle. ### An OVN L3 router tool ### Link: https://bugs.launchpad.net/neutron/+bug/2103521 The goal of this tool is: - To be able to list the current GW LRP assignment, according to the ``HA_Chassis_Group``. It will show the GW chassis assignation level (according to the priority) and the number of routers per chassis. - To be able to reschedule the current assignments. In case of unbalance (chassis deletion, router deletion), this tool will allow to reschedule the GW chassis across the existing LRPs. This is something that is useful to cloud operators that currently must manually try and re-balance LRPs. Status: Approved ### Alembic idempotency ### Link: https://bugs.launchpad.net/neutron/+bug/2100770 This request comes from an issue seen in RHOSO18 with a DB migration back port. It is not possible to change the cycle milestones (last DB migrations of each cycle), thus the D/S migrations (in U/S are forbidden) are done before these milestones. The problem happens when a user, that is already in the last DB migration step, needs to re-execute the DB migration tool to receive the new back ported migration. That will fail because it is not possible to execute a DB migration script twice. This proposal includes: - Implementing a new test class that checks any new DB migration in order to ensure it works, as we found issues recently. - Enforce any new DB migration (code developers and reviewers) to be idempotent. - This would be supported on all existing migrations as well, not just from today forward. - Provide a usage guide on the alembic methods if necessary Status: Approved ### Stop DB drop migrations, with field drop exceptions ### Link: https://bugs.launchpad.net/neutron/+bug/2104160 In a DB migration, developers should add a TODO note to drop anything not used in the next SLURP release. That will prevent the case described in the bug, where a user executed the "expand" phase migration code with the old Neutron API code (as specified by the upgrade guide), resulting in an error due to a missing DB column, which was dropped by a DB migration script. The initial output of this bug is a new policy in the development guide. ### Create a restricted default policy for undefined API calls ### Link: https://bugs.launchpad.net/neutron/+bug/2098737 The goal of this RFE is to define a default restrictive rule for every non-defined policy in the Neutron API, as "oslo.policy" allows us to create a "default" policy that will be used in case the API call is not defined. The "default" Neutron policy is RULE_ADMIN_OR_OWNER, we propose to change this to RULE_ADMIN_ONLY. Any new API not defined in the policies would be executable only by the admin user. This change cannot be done now, due to the high number of missing API rules not defined that are using the default rule, see https://review.opendev.org/c/openstack/neutron/+/945687 - but this rule migration should be a background tasks for any team member that will improve the quality of the RBAC system in Neutron. Status: Approved ### Nova/Cinder cross-project ### We discussed two topics at the Nova/Cinder cross-project meeting. Project-Specific QoS Controls for Granular Resource Management. Driven by Bloomberg. Link: https://bugs.launchpad.net/neutron/+bug/2102184 Despite many questions still existing about the implementation, the Neutron team agreed to accept a spec describing it. The Neutron team agreed to have a per-project QoS policy that will affect to a non-defined set of resources (ports, networks, routers, FIPs). Bloomberg agreed to work on this later this cycle. For live-migration with OVN, Nova currently has a vif-plugged event timer to work-around any missed (or not sent) notifications. Link: https://bugs.launchpad.net/nova/+bug/2073254 The code for the multiple binding is in core OVN (23.09) and Neutron. Nova team will propose a patch to remove the condition in Nova and wait for the vif-plugged event when using the ML2/OVN backend as the condition should not happen any more. Patch link: https://review.opendev.org/c/openstack/nova/+/946950 ### Service role permissions ### The Octavia allowed address pair driver requires new service role permissions. Link: https://bugs.launchpad.net/neutron/+bug/2105502 Three patches proposed: - Add new default policy for device_id field on ports: https://review.opendev.org/c/openstack/neutron/+/861169 - Allow service role to create/update port device_id: https://review.opendev.org/c/openstack/neutron/+/947003 - Allow service role more RBAC access for Octavia: https://review.opendev.org/c/openstack/neutron/+/945329 ### L3/DHCP thread pool resizing ### Link: https://review.opendev.org/c/openstack/neutron/+/938411 This proposal is related to the eventlet removal topic. There is no direct replacement for ``eventlet.GreenPool``. The resizable mechanism does not provide a resource improvement in speed or memory and there is no kernel library that provides this functionality. The default and static maximum number of threads will be 32 (the current maximum). ### VXLAN physical networks ### Link: https://bugs.launchpad.net/neutron/+bug/2105855 The goal is to be able to schedule a VXLAN port depending on the physical mappings as the VTEP interfaces in each compute node could be connected to different physical networks. This would help improve the "networking-generic-switch" back end as it could use this new information. An alternative to this could be to implement a new type driver: l2vni, used for tunneled drivers (VXLAN) with a physical back end. A spec is required to study this proposal further. ### vlan_transparent ### Link: https://bugs.launchpad.net/neutron/+bug/2092174 Proposal to deprecate and remove the vlan_transparent config option. By default, the loaded drivers will determine if the functionality is supported or not. Status: Approved ### OVN "Add-Only" Sync Mode ### Link: https://bugs.launchpad.net/neutron/+bug/2099818 Proposal to add a new OVN sync mode option that will only add things to the OVN database and never remove from either OVN or Neutron. There were a few worries, as turning-off delete might just make things more out of sync, and not address any issues being seen in ovn-controller or ovn-northd. It was also pointed out that we did spend some time over past cycles tagging neutron-owned objects in OVN explicitly, and there might just be some additional edge cases we need to fix. This might address the issue where other objects change unexpectedly. Need to discuss further at future Drivers meeting as submitter did not attend. ### RFE discussions ### On-demand topic to discuss any in-progress or proposed RFE changes, please see etherpad for more information. [0] https://etherpad.opendev.org/p/apr2025-ptg-neutron [1] https://etherpad.opendev.org/p/neutron-eventlet-deprecation [2] https://etherpad.opendev.org/p/apr2025-ptg-eventlet

1 0

[watcher] Cancelling May 1st weekly meeting
by Douglas Viroel 24 Apr '25

24 Apr '25

Hi all, Since most participants will be out on May 1st, due to local holidays, we agree[1] to cancel next week's meeting. We will meet again on May 8th. [1] https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-04-24-12.00… BR, -- Douglas Viroel - dviroel

1 0