March 2021 - openstack-discuss - lists.openstack.org

Fw: Aw: Re: OpenStack Victoria - Kolla-Ansible - Cinder - iSCSI-backend - Update driver status failed: config is uninitialized.
by Stefan Kelber 21 Mar '21

21 Mar '21

1 1

OpenStack Victoria - Kolla-Ansible - Cinder - iSCSI-backend - Update driver status failed: config is uninitialized.
by Stefan Kelber 21 Mar '21

21 Mar '21

3 2

iPXE update/configuration for the undercloud.
by Kendrick 21 Mar '21

21 Mar '21

I have a melanox connectx3 and a few broadcom systems that do not properly pxe boot, using maas the broadcoms work fine. I was looking around and one of the solutions to similar problems from 2017 and 19 were to use a different version of the ipxe files. I was hoping to know what settings/changes/scripts openstack undercloud used so i can make sure the connectx3 support is built in to the ipxe file and what files needed to be copied where from the source buld to the containers since the containers have about 20 sets of the ipxe files from what i can see when i use find to locate them from the host. Regards Kendrick

1 0

[all][tc] Dropping lower-constraints testing from all projects
by Ghanshyam Mann 19 Mar '21

19 Mar '21

Hello Everyone, You might have seen the discussion around dropping the lower constraints testing as it becomes more challenging than the current value of doing it. Few of the ML thread around this discussion: - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521… - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390… As Oslo and many other project dropping or already dropped it, we should decide it for all other projects also otherwise it can be more changing than it is currently. We have not defined it in PTI or testing runtime so it is always up to projects if they still want to keep it but we should decide a general recommendation here. -gmann

12 46

[tripleo][ci] ovb featureset01/35 and other jobs are down
by Wesley Hayutin 19 Mar '21

19 Mar '21

Greetings, ATM, the RDO team is working w/ Vexxhost to diagnose an outage in vexxhost that has caused various problems w/ heat stacks and now overcloud node registration and introspection. The issue is tracked w/ vexx and https://bugs.launchpad.net/tripleo/+bug/1920101. The third party check jobs are not expected to pass at this time. We'll follow up when we have more information. Thank you

1 0

[tripleo] Nominate David J. Peacock (dpeacock) for Validation Framework Core
by Gaël Chamoulaud 19 Mar '21

19 Mar '21

Hi TripleO Devs, David is already a key member of our team since a long time now, he provided all the needed ansible roles for the Validation Framework into tripleo-ansible-operator. He continuously provides excellent code reviews and he is a source of great ideas for the future of the Validation Framework. That's why we would highly benefit from his addition to the core reviewer team. Assuming that there are no objections, we will add David to the core team next week. Thanks, David, for your excellent work! -- Gaël Chamoulaud - (He/Him/His) .::. Red Hat .::. OpenStack .::. .::. DFG:DF Squad:VF .::.

9 12

[Cinder] Review pretty please
by Sam Morrison 19 Mar '21

19 Mar '21

Hi Cinder cores, I've had a simple review [1] waiting for several months, could I please get some feedback on this. Thanks! Sam [1] https://review.opendev.org/c/openstack/cinder/+/764875

3 2

[ops] Bandwidth problem on computes
by Jahson Babel 19 Mar '21

19 Mar '21

Hello everyone, I have a bandwidth problem between the computes nodes of an openstack cluster. This cluster runs on Rocky version with OpenVSwitch. To simplify I'll just pick 3 servers, one controller and two computes nodes all connected to the same switch. Every server is configured with two 10G links. Those links are configured in LACP /teaming. From what I understand of teaming and this configuration I should be able to get 10Gbps between all three nodes. But if I iperf we are way below this : compute1 # sudo iperf3 -c compute2 -p 5201 Connecting to host compute2, port 5201 [ 4] local X.X.X.X port 44946 connected to X.X.X.X port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 342 MBytes 2.87 Gbits/sec 137 683 KBytes [ 4] 1.00-2.00 sec 335 MBytes 2.81 Gbits/sec 8 501 KBytes Plus the problem seems to be only present with incoming traffic. Which mean I can almost get the full 10gbps if I iperf from a compute to the controller. compute1 # sudo iperf3 -c controller -p 5201 Connecting to host controller, port 5201 [ 4] local X.X.X.X port 39008 connected to X.X.X.X port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1.10 GBytes 9.41 Gbits/sec 0 691 KBytes [ 4] 1.00-2.00 sec 1.09 GBytes 9.38 Gbits/sec 0 803 KBytes If I do the opposite I get the same results I was getting between the 2 computes. From the tests we've done it seems related to the openstack's services, specifically neutron or OpenVSwitch. From the time those services are running we can't get the full bandwidth. Stopping the services won't fix the issue, in our case removing the packages and rebooting is the only way to obtain the full bandwidth between computes. I voluntarily didn't mention VMs to simplify the question but of course this behavior can also be observed in VMs Knowing that we can achieve 10Gbps it doesn't seems related to the hardware nor the OS. That why we suspect OpenStack's services. But I couldn't find any evidence or misconfiguration that could confirm that. So if anyone got some hints about that kind of setup and/or how mitigate bandwidth decrease I would appreciate. Let know if you need more info. Thanks in advance, Jahson

2 2

Re: [nova] Train: how to use newer API microversion
by Eugen Block 19 Mar '21

19 Mar '21

Alright, I made it work it seems. After I added the new endpoints (v2.1) and disabled the old ones (v2) I restarted nova-api service. This allowed me to use microversion 2.37 to use the option "--nic none", so that works as expected now. I just don't know yet if there are any clients that require v2 so for now I let them in "disabled" state. Thanks, Eugen Zitat von Eugen Block <eblock(a)nde.ag>: >> If you (or your end users) rely on the legacy APIs, you can have both >> like this (192.0.2.40 is the example IP address of the API host; the >> /compute could be :some_port if you prefer that): > > I started with disabling the old endpoints but then I couldn't use > compute at all to create a new instance. There must be something > still relying on the old endpoint but I can't find it right now. > I'll give it another shot tomorrow. Thanks for your input. > > > Zitat von Radosław Piliszek <radoslaw.piliszek(a)gmail.com>: > >> On Thu, Mar 18, 2021 at 3:50 PM Eugen Block <eblock(a)nde.ag> wrote: >>> I also found that already, but it doesn't describe how I can move from >>> v2 to v2.1 in order to use only the newer API. Do you have any >>> information about that? >> >> If you (or your end users) rely on the legacy APIs, you can have both >> like this (192.0.2.40 is the example IP address of the API host; the >> /compute could be :some_port if you prefer that): >> >> +----------------------------------+-----------+--------------+----------------+---------+-----------+------------------------------------------------+ >> | ID | Region | Service Name | Service Type | Enabled | >> Interface | URL | >> +----------------------------------+-----------+--------------+----------------+---------+-----------+------------------------------------------------+ >> | xxx | RegionOne | nova | compute | True | public >> | http://192.0.2.40/compute/v2.1 | >> | xxx | RegionOne | nova_legacy | compute_legacy | True | public >> | http://192.0.2.40/compute/v2/$(project_id)s | >> +----------------------------------+-----------+--------------+----------------+---------+-----------+------------------------------------------------+ >> >> If you don't need the legacy APIs, you can delete their endpoints. >> >> -yoctozepto

1 0

[keystone][kolla][horizon] versioned or unversioned keystone endpoints?
by Mark Goddard 19 Mar '21

19 Mar '21

Hi, There seems to be some inconsistency around whether Keystone endpoints in the catalog should be versioned or not. Specifically, should they have a /v3 suffix? I did a survey of code using keystone-manage bootstrap via codesearch: * Kolla Ansible: unversioned * DevStack: unversioned * puppet-keystone: unversioned * Keystone install guides: versioned * OSA: unversioned I imagine that when v2 was around, the endpoint needed to be unversioned. But was there a point when it became recommended to add a version? I'm asking because of an issue in horizon when downloading a clouds.yaml file for application credentials. If the auth_url field is unversioned, then some older client libraries will fail with a Not Found error during e.g. openstack server list. I tested using Stein and Train U-C. The former fails, the latter works. If I use Stein U-C, then update keystoneauth1 to 3.17.3 (from Train U-C), it works. Thanks, Mark

1 0