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

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

29 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 29 Apr '24

29 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 29 Apr '24

29 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 29 Apr '24

29 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 29 Apr '24

29 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

[kolla] Weekly meeting cancelled on 1st of May
by Michał Nasiadka 29 Apr '24

29 Apr '24

Hello Koalas, Due to 1st of May being public holiday in some European countries (including Poland) - Kolla weekly meeting is cancelled. See you next week - 8th May. Michal

1 0

[neutron] Bug deputy - week of Apr 22
by Sławek Kapłoński 28 Apr '24

28 Apr '24

Hi, I was bug deputy last week and below is summary of what new bugs opened for Neutron during that time: ## High - https://bugs.launchpad.net/neutron/+bug/2063043 - octavia/ovn: filedescriptor out of range in select() - assigned to Fernando Royo ## Medium - https://bugs.launchpad.net/neutron/+bug/2063081 - [ovn] connectivity to load balancer with FIP from a server connected to a router with external gateway - assigned to Fernando Royo - https://bugs.launchpad.net/neutron/+bug/2063459 - # DHCP agent might use default gateway of unrouted subnets - assigned to Sebastian Lohff, patch already proposed ## Low - https://bugs.launchpad.net/neutron/+bug/2063669 - DNS extensions reported as available even if not enabled - unassigned, seems like kind of low hanging fruit for someone who wants to start ## Others - https://bugs.launchpad.net/neutron/+bug/2063463 - [ovn-octavia-provider] hairpin_snat_ip not set - unassigned -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Losing connection when connecting br-ex to bond
by sarasoltanm2000＠gmail.com 28 Apr '24

28 Apr '24

The problem started from where I realized I couldn't ping or ssh the instances in openstack then I realized that it was a networking problem and that br-ex was not connected to my interfaces. for some reason I had to create a bond with a static private ip address of the second interface. (172.16.8.2/24). so to solve this problem I tried to connect the bond to the br-ex but as soon as I connect the bond to br-ex I get disconnected from the server (server cannot ping its gateway) and br-ex state goes down, when I connect it to the bond by the following command: sudo ovs-vsctl add-port br-ex bond0 and when I try to bring the bridge br-ex back up, the bond is automatically deleted from the ports. this is the configuration of bridges before adding the bond port: #ovs-vsctl show Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port br-ex Interface br-ex type: internal Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-int Interface br-int type: internal Port "tapf556c-c7" tag: 1 Interface "tapf556c-c7" type: internal Port "tapd2980-19" tag: 4095 Interface "tapd2980-19" type: internal Port "qr-8ea26-da" tag: 4095 Interface "qr-8ea26-da" type: internal Port "tap89cc3-c0" tag: 2 Interface "tap89cc3-c0" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} ovs_version: "2.12.0" any idea why this happens and what is the solution? btw the instance is not connected to a router and it is basically connected to 2 networks (172.16.8.32/28 and 172.16.8.48/28)

2 1