November 2022 - openstack-discuss

[nova][placement][tempest] Hold your rechecks
by Sylvain Bauza 05 Dec '22

05 Dec '22

Sorry folks, that's kind of an email I hate writing but let's be honest : our gate is busted. Until we figure out a correct path for resolution, I hereby ask you to *NOT* recheck in order to not spill our precious CI resources for tests that are certain to fail. Long story story, there are currently two problems : #1 https://launchpad.net/bugs/1940425 nova-ovs-hybrid-plug and nova-next jobs 100% fail due to a port remaining in down state. #2 https://bugs.launchpad.net/nova/+bug/1960346 nova-lvm job 100% fails due to a volume detach failure probably due to QEMU #1 is currently investigated by the Neutron team meanwhile a patch [1] has been proposed against Zuul to skip the failing tests. Unfortunately, this patch [1] is unable to merge due to #2. #2 has a Tempest patch that's being worked on [2] but the current state of this patch is WIP. We somehow need to have an agreement on the way forward during this afternoon (UTC) to identify whether we can reasonably progress on [2] or skip the failing tests on nova-lvm. Again, sorry about the bad news and I'll keep you informed. -Sylvain [1] https://review.opendev.org/c/openstack/nova/+/865658/ [2] https://review.opendev.org/c/openstack/tempest/+/842240

2 5

[Magnum] ls /etc/cni/net.d/ is emty
by Nguyễn Hữu Khôi 01 Dec '22

01 Dec '22

Hello guys. I use Magnum on Xena and I custom k8s cluster by labels. But My cluster is not ready and there is nothing in /etc/cni/net.d/ and my cluster said: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized And this is my labels kube_tag=v1.21.8-rancher1,container_runtime=containerd,containerd_version=1.6.10,containerd_tarball_sha256=507f47716d7b932e58aa1dc7e2b3f2b8779ee9a2988aa46ad58e09e2e47063d8,calico_tag=v3.21.2,hyperkube_prefix= docker.io/rancher/ Note: I use Fedora Core OS 31 for images. Thank you. Nguyen Huu Khoi

2 3

[kolla-ansible][Yoga][Magnum] How to delete a cluster containing errors
by wodel youchi 30 Nov '22

30 Nov '22

Hi, I have a magnum cluster stack which contains errors in its constituents, some of the VMs (minions) that belong to that cluster do longer exist. When I try to delete the stack it fails, and I get DELETE aborted (Task delete from ResourceGroup "kube_minions" [fddb3056-9b00-4665-b0d6-c3d3f176814b] Stack "testcluter01-puf45b6dxmrn" [d10af7f2-6ecd-442b-b1f9-140b79e58d13] Timed out) Is there a way to force the deletion to proceed even with those errors? Regards.

3 6

[cinder] Bug report from 11-23-2022 to 11-30-2022
by Sofia Enriquez 30 Nov '22

30 Nov '22

No meeting today due to Antelope Midcycle-1 (R-18). This is a bug report from 11-23-2022 to 11-30-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1998083 "volume_attachement entries are not getting deleted from DB." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1997980 "rbd: 'error updating features for image' when enabling multi-attach." Fix proposed to master. Low - https://bugs.launchpad.net/cinder/+bug/1997876 "Ceph backup: Improve error message when creating an incremental backup of a non-RBD volume." Unassigned. Cheers, Sofia -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[cinder] 2023.1 R-16 virtual mid cycle on 30th November (today)
by Rajat Dhasmana 30 Nov '22

30 Nov '22

Hello Argonauts, The first 2023.1 (Antelope) mid cycle R-16 will be held on 30th November (today) with the following details: Date: 30th November 2022 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 Etherpad: https://etherpad.opendev.org/p/cinder-antelope-midcycles Thanks and regards Rajat Dhasmana

1 0

[neutron][releases] Proposing to EOL Train networking-ovn
by Rodolfo Alonso Hernandez 30 Nov '22

30 Nov '22

Hello: The transition of this branch to EM was done 1,5 years ago [1]. During this time the maintenance of Train networking-ovn has continued. However, due to the lack of time and personal resources, we can't properly maintain it. That leads to problems like [1]. The ML2/OVN driver was successfully merged in the Neutron repository in Ussury. We continue the development and improvement of this ML2 mechanism driver. A patch to mark this branch as EOL will be pushed in two weeks. If you have any inconvenience, please let me know in this mail chain or in IRC (ralonsoh, #openstack-neutron channel). You can also contact any Neutron core reviewer in the IRC channel. Regards. [1]https://review.opendev.org/c/openstack/releases/+/790760 [2]https://bugs.launchpad.net/neutron/+bug/1997262

1 0

Re: Unable to access Internet from an instance and accessing instance using floating-point IPs from external network
by Eugen Block 30 Nov '22

30 Nov '22

So you did modify the default security-group, ports 8000 and 8080 are not open by default. Anyway, can you please clarify what doesn't work exactly? Does the instance have an IP in the public network but the router is not pingeable (but that is not necessarily an issue) and you can't access it via which protocols? Does SSH work? Is the access blocked by a http_proxy? Zitat von vincent lee <vincentlee676(a)gmail.com>: > To add on to my previous email, I have attached an image of my security > group as shown below. > > Best regards, > Vincent > > On Tue, Nov 22, 2022 at 3:58 AM Eugen Block <eblock(a)nde.ag> wrote: > >> Just one more thing to check, did you edit the security-group rules to >> allow access to the outside world? >> >> Zitat von Adivya Singh <adivya1.singh(a)gmail.com>: >> >> > it should be missing a default route most of the time. >> > or check IP tables on router namespace the DNAT and SNAT are working >> > properly >> > >> > >> > >> > On Tue, Nov 22, 2022 at 9:40 AM Tobias McNulty <tobias(a)caktusgroup.com> >> > wrote: >> > >> >> On Mon, Nov 21, 2022 at 7:39 PM vincent lee <vincentlee676(a)gmail.com> >> >> wrote: >> >> >> >>> After reviewing the post you shared, I believe that we have the correct >> >>> subnet. Besides, we did not modify anything related to the cloud-init >> for >> >>> openstack. >> >>> >> >> >> >> I didn't either. But I found it's a good test of the network! If you are >> >> using an image that doesn't rely on it you might not notice (but I >> >> would not recommend that). >> >> >> >> >> >>> After launching the instances, we are able to ping between the >> instances >> >>> of the same subnet. However, we are not able to receive any internet >> >>> connection within those instances. From the instance, we are able to >> ping >> >>> the router IP addresses 10.42.0.56 and 10.0.0.1. >> >>> >> >> >> >> To make sure I understand: >> >> - 10.42.0.56 is the IP of the router external to OpenStack that provides >> >> internet access >> >> - This router is tested and working for devices outside of OpenStack >> >> - OpenStack compute instances can ping this router >> >> - OpenStack compute instances cannot reach the internet >> >> >> >> If that is correct, it does not sound like an OpenStack issue >> necessarily, >> >> but perhaps a missing default route on your compute instances. I would >> >> check that DHCP is enabled on the internal subnet and that it's >> providing >> >> everything necessary for an internet connection to the instances. >> >> >> >> Tobias >> >> >> >> >> >> >> >> >> >> >> > > -- > thanks you. > vincentleezihong > 2garnet > form2

1 0

[all][tc] Technical Committee next weekly meeting on 2022 Nov 30 at 1600 UTC
by Ghanshyam Mann 30 Nov '22

30 Nov '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2022 Nov 30, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Nov 29 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[Kolla-ansible][Neutron] VMs not getting public IPs if attached directly to public subnet
by wodel youchi 30 Nov '22

30 Nov '22

Hi, We have an HCI deployment with 3 controllers and 9 compute/storage nodes. Two of the controllers have the role of neutron server. The platform uses two bonded interfaces : bond1 : is used for : *neutron_external_interface* bond0 : with many vlans on top of it to segregate the rest of the networks : - bond0 : vlan natif used for nodes deployment (dhcp, tftp, pxeboot) - bond0.10 : vlan 10 ceph public - bond0.20 : vlan 20 ceph cluster - bond0.30 : vlan 30 API - bond0.40 : vlan 40 tunnel * - bond0.50 : vlan 50 Public network, here are the public IPs of the 03 controllers, the public horizon VIP interface is created here.* In our configuration we have *"enable_neutron_provider_networks = yes"*, which means that an instance can have a public IP directly without using a virtual-router + NAT. But it does not work. If we create and instance with a private network, then we attach to it a floating IP, the VM is reachable from the Internet, but if we attach the VM directly to the public network, it does not get an IP address from the public pool, we think it's a dhcp problem but we could not find the source, we think it's the *Vlan part.* The controllers are in Vlan 50, if we create a virtual-router it gets its public IP without any problem. But if we are not mistaken, if an instance is plugged directly into the public network, it uses bond1 to send its dhcp requests, but since this interface is not in vlan 50, the requests don't get to the controllers, is this right? If yes, is there a solution? can we use bond1.50 as an interface for kolla's *neutron_external_interface * instead? Regards.

3 3

[OVB - openstack-virtual-baremetal] - Douglas Viroel and Chandan Kumar as core
by Harald Jensas 30 Nov '22

30 Nov '22

Hi, After discussions with Douglas, Chandan and Ronelle Landy I would like to suggest adding Douglas and Chandan to the OVB core team. The repository have very little activity, i.e there is not a lot of review history to base the decision on. I did work with both individuals when onboarding new clouds to run TripleO CI jobs utilizing OVB, they have a good understanding of how the thing works. If there are no objections, I will add them to them as core reviewers next week. Regards, Harald

3 3