January 2025 - openstack-discuss - lists.openstack.org

[neutron][upgrades] Linuxbridge driver removal and migration
by Brian Haley 17 Jan '25

17 Jan '25

Hi Stackers, In 2022, during the Zed cycle, the Neutron team took a step at marking some items as experimental. One of those was the Linuxbridge driver. The reason was due to it being unmaintained for a number of cycles, and no one was able to take on its ownership. The implication of this decision was that it was consider deprecated, even if not given an official warning message. In doing this, all gate jobs were moved into the experimental queue, feature-parity with other drivers was deemed unnecessary, and bug fixing was considered best-effort. Since then, both major distros have stopped supporting new deployments using Linuxbridge, and have been mainly focused on OVN. So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the code from the tree [1]. After 5 cycles of being considered experimental without any investment it just makes sense. We plan on doing this in the current Epoxy cycle. We realize that there are still deployments using Linuxbridge, and hopefully they have been looking at migration strategies since we originally marked the code experimental. This email is another push to the user community to start looking at this, especially if you are planning any new deployments. There has been at least one migration guide written at [2] (thanks Jim!), and at this point I would encourage those still using Linuxbridge to look at it and start asking any questions they have so we have the chance to make it better and can make that process easier. Thanks for reading, -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/neutron/+/845181 [1] https://review.opendev.org/c/openstack/neutron/+/927216 [2] https://www.jimmdenton.com/migrating-lxb-to-ovn/

11 14

[magnum] GPU support with magnum
by Satish Patel 17 Jan '25

17 Jan '25

Folks, We are running magnum with openstack to spin up k8s clusters and everything works as expected. Now I want GPU support so we can do some AI/ML stuff with k8s. Does magnum support GPU and how does it work? In the past I used GPU in passthrough mode to expose hardware to VMs but not sure how it works for k8s and what are the challenges?

4 11

openstack ssl
by engineer2024 17 Jan '25

17 Jan '25

The present model for openstack API services uses keystone for authentication mechanism for the REST API. is it possible to test the api calls directly using the server/port of a API service, bypassing the keystone URI ? does this require any modification in the configuration of the openstack service ? Thanks

1 0

[neutron] Using address scopes in a DVR environment breaks floating IPs
by Lukas Steiner 17 Jan '25

17 Jan '25

Hi all, I hope to get some advice here if we’re doing something wrong or ran into a bug. We have an OpenStack environment (wallaby) with Distributed Virtual Router (DVR) enabled (compute nodes use DVR_NO_EXTERNAL agent mode, network nodes use DVR_SNAT) and we would like to onboard our provider network to a subnet pool part of an address scope to allow routed self-service networks. But as soon as the provider network is part of an address scope, the floating IP feature stops working. After debugging we found that adding the network to an address scope results in an additional set of firewall rules in the router and snat network namespaces which blocks cross-scope traffic. But floating IPs should be the exception to that and there are indeed rules that explicitly allow them by setting a mark in the iptables mangle table: -A neutron-l3-agent-floatingip -d <floating-ip>/32 -i qg-<random-id> -j MARK --set-xmark 0x4000000/0xffff0000 We can find these rules in the qrouter namespaces, but they’re missing in the snat namespaces. If we add the rule manually to the snat namespace, the floating IP is working again. If we switch the compute nodes to DVR agent mode, it also works, as the snat namespace is not used. I have already searched for bugs and changes in the DVR router code since wallaby but can’t find anything which is not already patched in wallaby. So, I’m wondering if we have an unsupported setup with combining dynamic routing with DVR and centralized network nodes or facing a long running neutron bug. Maybe someone has a similar setup or can confirm that this use case should be supported? Regards, Lukas

1 0

[Neutron][operators] LinuxBridge to OVN Outreach
by Daniel Failing 17 Jan '25

17 Jan '25

Dear operators of Neutron deployments using LinuxBridge, This mail is to target operators who plan to move away from neutron LinuxBridge as well. In our setup we are currently planing to move away from LinuxBridge and use OVN instead. Based on the last PTGs survey with quite a few deployments using LinuxBridge and it being marked experimental for some time, we feel there could be a common ground and pain points. We were wondering how many other operators have the same problems and want to share knowledge and if necessary consolidate code written for a potential migration. Knowing there are quite some different deployments, we most likely will not be able to find the golden solution that works for everyone, but we could strive for not making the same mistakes multiple times in different deployments. We are located in European timezones, if there are others interested in a zoom/jitsi call, please let me know your timezones/time preferences, so we find a good slot. Otherwise I can propose one of the following dates already: Friday, Jan 24st 2 or 3pm UTC Tuesday, Jan 28st 10am UTC Tuesday, Jan 28st 3:30pm UTC Wednesday, Jan 29st 10am UTC Friday, Jan 31st 2 or 3pm UTC Best, Daniel CERN Cloud Infrastructure [1] original thread: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

Re: Dalmatian Devstack: Empty Port Binding section in Horizon
by Lajos Katona 17 Jan '25

17 Jan '25

Hi, I checked and I hoped that this SDK patch : https://review.opendev.org/c/openstack/openstacksdk/+/915902 or SDK 4.2.0 is enough (for binding details at least) but something else is missing. Could you please open a bug report for this issue, I try to check where to fix it. Lajos Katona (lajoskatona) <berndbausch(a)gmail.com> ezt írta (időpont: 2025. jan. 14., K, 13:25): > Thanks much, Lajos! > > > > It was installed by Devstack with git_clone https://opendev.org/openstack/horizon.git > /opt/stack/horizon stable/2024.2. Furthermore, under /opt/stack/horizon/ > horizon.egg-info I find a file named pbr.json, which contains > > > > {"git_version": "4bcc3dcea", "is_release": false} > > > > I hope that makes it clear what I am using! Or is there another way of > obtaining the Horizon release number? > > > > Of the list of patches you shared, the ones that seem relevant (SDK for > neutron ports, SDK for neutron networks) were merged in August and June, > respectively, which makes me think that should be included in my release. > > > > And since this is an HTML message now, I am adding two screenshots. Not > only port binding info, but also network provider info is missing. I can > confirm that this is the admin user. > > > > Kind regards, > > > > Bernd > > > > > > *From:* Lajos Katona <katonalala(a)gmail.com> > *Sent:* Tuesday, January 14, 2025 5:22 PM > *To:* berndbausch(a)gmail.com > *Cc:* openstack-discuss <openstack-discuss(a)lists.openstack.org> > *Subject:* Re: Dalmatian Devstack: Empty Port Binding section in Horizon > > > > Hi Bernd, > > Shall I ask which version of Horizon do you use? Recently some patches > were merged for changing to SDK in the background: > > > https://review.opendev.org/q/project:openstack/horizon+topic:%22bug/1999774… > > And to be sure if you hit an issue from that change series or something > else. > > > > Best wishes > > Lajos Katona (lajoskatona) > > > > <berndbausch(a)gmail.com> ezt írta (időpont: 2025. jan. 14., K, 4:43): > > Is there a known bug, either in Devstack or Horizon, that prevents Neutron > port binding details from being displayed? My googling did not find > anything. > > As admin, I open a port's details, and in the Binding section at the end of > the page, all I get is a bold text "VNIC Type". The CLI command "openstack > port show" does provide the details. Also on a Xena Devstack, Horizon > displays them[1]. Horizon's setup.py seems to be identical on both > releases, > as far as Neutron configuration is concerned. > > Thanks for any input. > > Bernd. > > [1] The Binding details I expect: > > Binding > > VNIC Type Normal > Host xena-202 > Profile None > VIF Type ovs > VIF Details > connectivity l2 > port_filter True > ovs_hybrid_plug False > datapath_type system > bridge_name br-int > >

2 1

[telemetry] Stepping down from core team
by Yadnesh Kulkarni 17 Jan '25

17 Jan '25

Dear Team, Due to my role change I will no longer be able to contribute to the Telemetry projects. I’ve decided to step down from the core team. Working on the Telemetry projects has been a truly rewarding and enriching learning experience. I’ve thoroughly enjoyed being part of this incredible journey and have gained a lot from collaborating with such talented and supportive individuals. Thank you all for your guidance, collaboration, and support throughout this time. Wishing the team continued success and growth! -- Yadnesh Kulkarni

1 0

[tc][freezer][watcher][release][requirement][oslo] projects need to refresh the DPL model for the next cycle
by Ghanshyam Mann 16 Jan '25

16 Jan '25

Hi All, As you know, we have five projects (listed below) in the DPL model. As per process[1], we need to reset the DPL model every cycle. The project team either needs to opt-in to the DPL model (refer to the document for exact steps[1]) or plan for the PTL election. 1. Freezer: https://review.opendev.org/c/openstack/governance/+/939484 2. Watcher: https://review.opendev.org/c/openstack/governance/+/939488 3. Release: https://review.opendev.org/c/openstack/governance/+/939486 4. Requirement: https://review.opendev.org/c/openstack/governance/+/939487 5. Oslo: https://review.opendev.org/c/openstack/governance/+/939485 [1] https://governance.openstack.org/tc/reference/distributed-project-leadershi… -gmann

1 0

[qa] QA office hours new time
by Ghanshyam Mann 16 Jan '25

16 Jan '25

Hi All, As informed by Martin[1], we are changing the QA office hours to Wed biweekly at 18.00 UTC. I have updated the meeting info[2] and wiki page[3]. This time might not suit many of you, so feel free to ping me on IRC if any topic/review needs urgent attention. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://review.opendev.org/c/opendev/irc-meetings/+/939480 [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee -gmann

1 0

[openstack-helm] Use Loci images by default
by Vladimir Kozhukalov 16 Jan '25

16 Jan '25

Hi, This is to announce multiple things: 1) OpenStack/Loci (a project for building OpenStack images) is currently equipped with periodic jobs that are run nightly. These jobs build images for 3 most recent OpenStack releases: - 2023.2 Bobcat - 2024.1 Caracal - 2024.2 Dalmatian Images are published to these two destinations: - docker.io/loci/* (which is known for its strict request rate limits) - quay.io/airshipit/* (which is much more tolerant to the number of requests) Images are tested before publishing with two basic deployment configurations: - compute-kit (Deploy minimal set of OpenStack components to run VMs) - cinder (Deploy Cinder with Ceph backend) 2) By default we are going to use Loci images published to the Quay registry [1]. All test jobs will be run with these images and this is also a recommendation for users to consume images from quay to mitigate possible rate limit issues. 3) OpenStack/OpenStack-Helm-Images project will build only non-OpenStack images. Primarily the motivation is to deduplicate the code base. Consequently, OpenStack images published nightly to docker.io/openstackhelm/* will not be updated after 2024.2. [1] https://review.opendev.org/c/openstack/openstack-helm/+/939426 -- Best regards, Kozhukalov Vladimir

1 0