April 2024 - openstack-discuss - lists.openstack.org

[neutron] neutron-dynamic-routing advertising IPv4 AND IPv6 routes for true MP-BGP OR running multiple BGP speakers per agent (host)?
by Christian Rohmann 30 Apr '24

30 Apr '24

Hello OpenStack-Discuss, when setting up Neutron Dynamic Routing [1] to advertise IPV4 floating IPs and also IPv6 tenant networks I ran into some questions / issues. I was just about to ask about them here on the ML, when I found the older thread [2] discussing the advertising of IPv6 routes (e.g. from tenant networks). There Sean mentioned [4] that even with MP-BGP support [3] it's required to have two BGP speakers. While [3] means IPv4 or IPv6 can be used to establish the BGP session itself to then advertise routes for either address family, it's not possible to advertise IPv4 AND IPv6 routes via the same session. To cut to the chase of this threat .... It's not uncommon to simply use individual (non Multi-Protocol) BGP sessions to exchange routes for IPv4 and IPv6 individually and to me this poses no issue to me. The problem with Neutron is though, that the os_ken dragent driver only supports one BGP speaker [5] per agent. This leads to only one of the BGP speakers (IPv4 or IPv6) running per individual (control plane, networking) host. Or am I not seeing something or am misreading the capabilities of the components involved? If not, I see two options for improvement here: 1) Enabling a BGP speaker to have more than one address family (dragent driver already has MP-BGP support via [3]), so the query fetching the routes [6] simply returns them both. 2) Somehow get more than one BGP speaker per dragent working by ... a) ... extending the driver to host more than one BGP speaker b) ... extending dragent to have more than one driver instance Would love to hear how others have set up their dynamic routing and what your ideas are! Regards Christian [1] https://github.com/openstack/neutron-dynamic-routing [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/608302 [4] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846fead… [6] https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846fead…

3 4

[tc][all] OpenStack Technical Committee weekly summary and meeting agenda
by Goutham Pacha Ravi 30 Apr '24

30 Apr '24

Hello Stackers, We're slowly approaching Milestone-1 of the 2024.2 (Dalmatian) release cycle [1]. As you observe, there is a buzz of activity across all OpenStack repositories as we've just gotten out of our design and planning event. I hope you've been enjoying the PTG summaries that have been posted thus far; I would especially recommend reading through the summary JayF put up for the Technical Committee meetings [2]. Allow me to take you through the latest news from the Technical Committee: === Weekly Meeting === Last week's TC meeting was held on IRC on Apr 23rd, 2024. The meeting was logged to eavesdrop [3]. Our main topic of discussion was about the fate of unmaintained branches, and the discussion was timely given that Elod Iles from the OpenStack Release Management SIG brought a discussion to this list about transitioning the "stable/zed" branch of all release-cycle deliverables to "unmaintained/zed" [5]. This process is underway [6]. Concerns were expressed that the unmaintained process may be easy for teams to opt in, and the burden on the "unmaintained-core" team is growing with each branch. Project Teams are expected to actively assist in transitioning branches to end-of-life. Since this isn't happening, and since the TC has noted that a number of projects have CI (Zuul) configuration errors on these "unmaintained" branches, it was proposed that we be aggressive about proposing end-of-life for unmaintained branches. It was also argued that our release model is going too fast for real-world deployments to catch up, and transitioning a lot of branches simultaneously to EOL may impact many consumers. In the interest of time during the meeting, we decided not to interfere with the transition of stable/zed to "unmaintained/zed". We encourage project leaders to: - Get their CI configuration in order for any unmaintained branches - If there is no interest/time to maintain any unmaintained branch, please actively pursue the branch's EOL process [7] In the rest of the meeting, we went through open governance proposals. We have been distracted by the PTG and Action Items across OpenStack, so some of these proposals are lacking review attention. We'll be focusing on getting these adequate review attention in the coming week/s. The next TC meeting is today, Apr 30th, 2024, at 1800 UTC on OFTC's #openstack-tc channel [4]. The agenda feels light, but we'll try to address a number of TC trackers at this meeting. This meeting is enhanced by the community's participation. We'd especially invite project leaders (PTLs, DPLs, Core maintainers) to participate and propose topics. === Goal Proposals === I'd like to request a community review of the following OpenStack community goals and updates: - Migrate eventlet usages to asyncio (https://review.opendev.org/c/openstack/governance/+/902585) - Goal: Remove eventlet requirements from shared libraries (https://review.opendev.org/c/openstack/governance/+/916546) - Add timeline to remove enforce_scope in RBAC goal (https://review.opendev.org/c/openstack/governance/+/915179) === Governance Proposals === The following governance proposals are close to being merged: - Add option to move leaderless project to Inactive status (https://review.opendev.org/c/openstack/governance/+/914726) - Appoint Wenxiang Wu as PTL of Skyline | (https://review.opendev.org/c/openstack/governance/+/915108) - Transition Freezer project to DPL | (https://review.opendev.org/c/openstack/governance/+/914911) The following governance proposals are actively being discussed: - Add DPL model & liaison reset policy (https://review.opendev.org/c/openstack/governance/+/916833) - Update to include docs and miscellaneous repos for AC status (https://review.opendev.org/c/openstack/governance/+/915021) - Clarify the timeline for a project to move to Inactive state (https://review.opendev.org/c/openstack/governance/+/908880) The following governance proposals need some review attention: - Move openstack/kuryr and openstack/kuryr-libnetwork to Zun (https://review.opendev.org/c/openstack/governance/+/917517) - 2023 User Survey TC Question Analysis (https://review.opendev.org/c/openstack/governance/+/900516) And finally, please consider volunteering as an Election official for the next OpenStack elections! [8] Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://releases.openstack.org/dalmatian/schedule.html [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://meetings.opendev.org/meetings/tc/2024/tc.2024-04-23-18.00.log.html [4] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [5] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] https://review.opendev.org/q/topic:zed-unmaintained [7] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [8] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

[all][oslo] Removing Python 3.8 support
by Takashi Kajinami 30 Apr '24

30 Apr '24

Hello, I'm sending this to remind you of the fact that Python 3.8 support will no longer be part of the tested python versions for 2024.2 . Based on the plan, I'll drop Python 3.8 support from all oslo libraries and update the minimum python version from 3.8 to 3.9, in the final release of oslo deliverables. Please make sure that none of the master jobs are dependent on Python 3.8 . We faced some problems when we first attempted to remove python 3.8 support early and the removal was eventually reverted because of remaining usage of Focal and remaining lifecycle of Python 3.8. However now Python 3.8 is actually reaching its EOL, we may no longer attempt the same revert. https://governance.openstack.org/tc/reference/runtimes/2024.2.html Thank you, Takashi Kajinami -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[tc][election] A call for election officials for 2024.2
by Goutham Pacha Ravi 30 Apr '24

30 Apr '24

Hello Stackers, I'd like to express my gratitude to Ian Y Choi and Tony Breeds for their service as OpenStack's election officials for the 2024.1 term. A hallmark of our community has been its leadership and the guiding principles [1] we use when defining them. In Aug-Sep 2024, we're going to be electing the next set of OpenStack Project Team Leads as well as 4 members of the OpenStack Technical Committee. We've run a combined election for PTLs and TC seats in the past few years. We envision doing the same for this upcoming election. Most of the election process is automated, and election officials help execute and oversee this process [2]. If you're interested in being an election official, please reach out to me. If you've previously served as an election official, please do not hesitate to reach out. If we have enough volunteers, you may do us a great favor by mentoring those doing this for the first time. Thank you, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://governance.openstack.org/tc/reference/principles.html [2] https://governance.openstack.org/election/process.html

1 0

Re: [magnum][magnum-capi][cinder] Override csi plugin to override availability zone for cinder
by Satish Patel 30 Apr '24

30 Apr '24

Thanks for the quick response. I would like to have this in the MCAPI driver so we have more control on variables by labels. Because each deployment is different. I have created issue here: https://github.com/vexxhost/magnum-cluster-api/issues/366 On Mon, Apr 29, 2024 at 5:26 PM Mohammed Naser <mnaser(a)vexxhost.com> wrote: > Hi Satish, > > > Replies inline, as I’m trying to “decompose” this. 😊 > > > > *From: *Satish Patel <satish.txt(a)gmail.com> > *Date: *Monday, April 29, 2024 at 5:13 PM > *To: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > *Subject: *[magnum][magnum-capi][cinder] Override csi plugin to override > availability zone for cinder > > Folks, > > > > I have deployed a magnum with magnum-capi driver. Now trying to work with > a cinder for PV stuff and found some strange issue related to the > Availability Zone. > > > > My k8s cluster running in AZ: foo > > My Ceph/Cinder running in AZ: nova (default) > > > > I have created k8s cluster using magnum-capi selecting AZ: foo but when I > am trying to create/attach PV then getting an error saying invalid AZ. Ofc > because its in different AZ so I have add following snippet in Storage > class to override AZ of CSI > > > > allowedTopologies: - matchLabelExpressions: - key: > topology.cinder.csi.openstack.org/zone values: - nova > > > > So in this case, you do allow cross az attach inside OpenStack in order to > allow this, is this correct? Since the AZ of your storage != the AZ of > your compute nodes. > > > > PV creation completed successfully after applying the above change. Now > when I try to deploy ngnix and pass that PV then again I get a volume > affinity issue because worker nodes and volume are in different AZ. > > > > I did the following to change CSI plugin az to nova for worker node to > make it fix. > > > > kubectl label nodes kube-acrsf-default-worker-rxmg6-t7wzd > topology.cinder.csi.openstack.org/zone=nova --overwrite > > > > What is the proper workaround here for the above scenario and what would > be the proper way to fix it? > > > > In this case, what you’re doing is telling the node that it is running in > the `nova` AZ (which it is not!) > > > > Does magnum have Cinder CSI AZ label to override availability zone in > magnum template? > > > > > https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cin… > > > > I believe in this case, you’ll need to set the ignore-volume-az if I > understand correctly, it seems Magnum does not have a default label for > this. If you want to file an issue to the CAPI driver we can add an option > to enable this and make it ignore it. >

1 0

[magnum][magnum-capi][cinder] Override csi plugin to override availability zone for cinder
by Satish Patel 30 Apr '24

30 Apr '24

Folks, I have deployed a magnum with magnum-capi driver. Now trying to work with a cinder for PV stuff and found some strange issue related to the Availability Zone. My k8s cluster running in AZ: foo My Ceph/Cinder running in AZ: nova (default) I have created k8s cluster using magnum-capi selecting AZ: foo but when I am trying to create/attach PV then getting an error saying invalid AZ. Ofc because its in different AZ so I have add following snippet in Storage class to override AZ of CSI allowedTopologies: - matchLabelExpressions: - key: topology.cinder.csi.openstack.org/zone values: - nova PV creation completed successfully after applying the above change. Now when I try to deploy ngnix and pass that PV then again I get a volume affinity issue because worker nodes and volume are in different AZ. I did the following to change CSI plugin az to nova for worker node to make it fix. kubectl label nodes kube-acrsf-default-worker-rxmg6-t7wzd topology.cinder.csi.openstack.org/zone=nova --overwrite What is the proper workaround here for the above scenario and what would be the proper way to fix it? Does magnum have Cinder CSI AZ label to override availability zone in magnum template?

1 0

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 30 Apr '24

30 Apr '24

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

1 0

[ironic][nova-scheduler] "host_state" in nova filters has stale aggregate information
by Michael Sherman 30 Apr '24

30 Apr '24

Hi all, We’re running into an issue, where for two sites with 150-250 ironic nodes on a single conductor and nova-compute instance, we’ve started to get “no hosts available” errors from nova scheduler. We’re using the blazar-nova filter to match on hosts in specifically tagged aggregates. After adding some debug logs, I found that the “host_state” object passed to the filter seems to have out-of-date aggregate information. Specifically, if I query the system with “openstack aggregate show …” or “openstack allocation candidate list”, I see the correct aggregate for the nodes in question, but the contents of “host_state” reflect a previous state. This “staleness” does not seem to correct itself over time, but is resolved by restarting the nova-scheduler process (actually restarting the kolla docker container, but the same effect). However the issues return over the course of a couple hours. We haven’t increased the number of nodes, or otherwise changed the hardware, so I’m not sure what could have triggered this issue. Any advice on further debugging steps would be greatly appreciated. Thank you! -- Michael Sherman Infrastructure Lead – Chameleon Computer Science, University of Chicago MCS, Argonne National Lab

3 13

[publiccloud-sig] Meeting on May 1st will be skipped
by Felix Kronlage-Dammers 29 Apr '24

29 Apr '24

Hi everyone, This Wednesday (May 1st) the next meeting of the publiccloud sig would be scheduled. However in a lot of the european countries this is a public holiday. As such Tobias and I decided that we will skip this call. A lot of us will be at the OpenInfra Day Berlin on the 15th of May - which would be the date for the next publiccloud sig, as such the one meeting on the 15th will happen during coffee break at the OID berlin :) (More infos on the OID Berlin here: https://oideurope2024.openinfra.dev/germany/#:~:text=15%20May%202024%20%7C%….) regards 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

[oslo] Rootwrap configuration issues (sudoers entries?)
by Francesco Di Nucci 29 Apr '24

29 Apr '24

Hello, I am configuring oslo rootwrap on my OpenStack instance, but I could only find documentation about nova-rootwrap like here <https://docs.openstack.org/oslo.rootwrap/latest/user/usage.html>. On the compute nodes it is now working, while I'm having troubles with eg. network nodes. I have added a sudoers entry on the like of the nova one: neutron ALL = (root) NOPASSWD: /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf * But I don't know if it is correct, is there any documentation about it? Regards Francesco Di Nucci

2 3