November 2022 - openstack-discuss

[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 29 Nov '22

29 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 29 Nov '22

29 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 29 Nov '22

29 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

[openstack-ansible] Designate: role seems trying to update DNS server pools before syncing database
by Taltavull Jean-François 29 Nov '22

29 Nov '22

Hello, During the first run, the playbook 'os-designate-install.yml' fails and the 'designate-manage pool update' command produces the log line below: 'Nov 25 11:50:06 pp3controller1a-designate-container-53d945bb designate-manage[2287]: 2022-11-25 11:50:06.518 2287 CRITICAL designate [designate-manage - - - - -] Unhandled error: oslo_messaging.rpc.client.RemoteError: Remote error: ProgrammingError (pymysql.err.ProgrammingError) (1146, "Table 'designate.pools' doesn't exist")' Looking at the 'os_designate' role code shows that the handler ` Perform Designate pools update` is flushed before tables are created in the 'designate' database. O.S.: Ubuntu 20.04 OpenStack release: Wallaby OSA tag: 23.2.0 Regards, Jean-Francois

2 4

[neutron] neutron-db-manage multiple heads
by Eugen Block 29 Nov '22

29 Nov '22

Hi *, I'd like to ask you for advice on how to clean up my neutron db. At some point (which I don't know exactly, probably train) my neutron database got inconsistent, apparently one of the upgrades did not go as planned. The interesting thing is that the database still works, I just upgraded from ussuri to victoria where that issue popped up again during 'neutron-db-manage upgrade --expand', I'll add the information at the end of this email. Apparently, I have multiple heads, and one of them is from train, it seems as if I never ran --contract (or it failed and I didn't notice). Just some additional information what I did with this database: this cloud started out as a test environment with a single control node and then became a production environment. About two and a half years ago we decided to reinstall this cloud with version ussuri and import the databases. I had a virtual machine in which I upgraded the database dump from production to the latest versions at that time. That all worked quite well, I only didn't notice that something was missing. Now that I finished the U --> V upgrade I want to fix this inconsistency, I just have no idea how to do it. As I'm not sure how all the neutron-db-manage commands work exactly I'd like to ask for some guidance. For example, could the "stamp" command possibly help? Or how else can I get rid of the train head and/or how to get the train revision to "contract" so I can finish the upgrade and contract the victoria revision? I can paste the whole neutron-db history if necessary (neutron-db-manage history), please let me know what information would be required to get to the bottom of this. Any help is greatly appreciated! Thanks! Eugen ---snip--- controller01:~ # neutron-db-manage upgrade --expand [...] alembic.script.revision.MultipleHeads: Multiple heads are present for given argument 'expand@head'; 633d74ebbc4b, I38991de2b4 controller01:~ # neutron-db-manage current --verbose Running current for neutron ... INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. Current revision(s) for mysql+pymysql://neutron:XXXXX@controller.fqdn/neutron: Rev: bebe95aae4d4 (head) Parent: b5344a66e818 Branch names: contract Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/ussuri/contract/bebe95aae4d4_.py Rev: 633d74ebbc4b (head) Parent: 6c9eb0469914 Branch names: expand Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py Rev: I38991de2b4 (head) Parent: 49d8622c5221 Branch names: expand Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/victoria/expand/I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py OK ---snip---

2 10