- openstack-discuss - lists.openstack.org

[i18n] questions for the user survey
by Brian Rosmaita 21 Oct '22

21 Oct '22

Hello people interested in internationalization, At the PTG this week, the i18n SIG drafted some questions for the 2023 OpenStack User Survey. Please look them over and leave any comments on the etherpad: https://etherpad.opendev.org/p/oct2022-ptg-openstack-i18n-user-survey-quest… We need to get these to the Foundation quickly, so please leave your comments before 1200 UTC on Monday 24 October.

1 0

[glance] Slow image download when using glanceclient
by Lucio Seki 20 Oct '22

20 Oct '22

Hi glance experts, I'm using the following code to download a glance image: ``` from glanceapi import client ... glance = client.Client(GLANCE_API_VERSION, session=sess) ... with open(path, 'wb') as image_file: data = glance.images.data(image_id) for chunk in tqdm(data, unit='B', unit_scale=True, unit_divisor=1024): image_file.write(chunk) ``` And I get a speed around 3kB/s. It would take months to download an image. I'm using python3-glanceclient==3.6.0. I even tried: ``` for chunk in tqdm(data, unit='B', unit_scale=True, unit_divisor=1024): pass ``` to see if the bottleneck was the disk I/O, but didn't get any faster. In the same environment, when I use the glance CLI instead: ``` glance image-download --file $path $image_id ``` I get hundreds of MB/s download speed, and it finishes in a few minutes. Is there anything I can do to improve the glanceclient performance? I'm considering using subprocess.Popen(['glance', 'image-download', ...]) if nothing helps... Regards, Lucio

3 6

[all][tc] 2023.1 Antelope TC-PTG Planning
by Ghanshyam Mann 20 Oct '22

20 Oct '22

Hello Everyone, As you already know that the 2023.1 cycle virtual PTG will be held between Oct 17th - 21[1]. I have started the preparation for the Technical Committee PTG sessions. Please do the following: 1. Fill the below poll as per your availability. - https://framadate.org/yi8LNQaph5wrirks 2. Add the topics you would like to discuss to the below etherpad. - https://etherpad.opendev.org/p/tc-2023-1-ptg NOTE: this is not limited to TC members only; I would like all community members to fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030041.… -gmann

2 4

[PTG][nova][neutron] Nova-Neutron cross-team meetings
by Rodolfo Alonso Hernandez 20 Oct '22

20 Oct '22

Hello all: The Nova-Neutron cross-team sessions today, starting at 13UTC, will be on Nova channel "bexar". In any case, I'll send an update in our IRC channel and I'll keep "mitaka" session open to redirect people to "bexar". Regards.

1 0

[dev][infra][tact-sig] Updating Zuul's default-ansible-version to 6
by Jeremy Stanley 19 Oct '22

19 Oct '22

Just a heads up for folks not following the OpenDev Collaboratory's service-announce mailing list... now that Zed is officially released, we'll be increasing the default Ansible version for Zuul jobs from 5 to 6 in preparation for Zuul to drop Ansible 5 support in coming weeks. See the full announcement here: https://lists.opendev.org/pipermail/service-announce/2022-October/000046.ht… -- Jeremy Stanley

2 1

[horizon] Cancelling Two Weekly Meeting
by vishal manchanda 19 Oct '22

19 Oct '22

Hello Team, As discussed in Yesterday's PTG meeting, there will be no horizon weekly meeting for today and next week. The next horizon weekly meeting will be on 2nd November. Thanks & Regards, Vishal Manchanda

1 0

DC DR Setup Queries
by KK CHN 19 Oct '22

19 Oct '22

List, We are having a client DC running on HP( HP simplivity) HCI servers, With VMware ( Vsphere 7.0) only few VMs running on it. (11 VMs maximum all Linux VMs). The DR site also having the same HCI setup another location. ( The VMs are replicated to DR site with HP simplivity). We are planning to use Openstack for both DC and DR solutions with Wallaby or Xena version with KVM as hypervisor to replace the proprietary S/W and H/W vendor locking. The requirement is to Setup a Stable DC- DR solution. Totally confused How to setup a best Dc- DR solution for this purpose. The DR setup can be possible / advisable with Zero down time ?( or manual DR site uping with downtime of hours ) ? What are the available/suggested DC-DR replication mechanisms for high degree of application data protection and service availability? Kindly advise.. Thanks in advance, Krish

2 2

[cloudkitty] Another core team cleanup
by Pierre Riteau 19 Oct '22

19 Oct '22

Hello, Almost exactly two years since the last core team cleanup [1], it's probably time to have another one. I don't think we have heard from these contributors in the last couple of years: Justin Ferrieu jferrieu(a)objectif-libre.com Luis Ramirez luis.ramirez(a)opencloud.es Luka Peschke mail(a)lukapeschke.com Maxime Cottret maxime.cottret(a)gmail.com Stéphane Albert sheeprine(a)nullplace.com Jeremy Liu liuj285(a)chinaunicom.cn Is everyone okay with removing cloudkitty-core membership for these users? Cheers, Pierre Riteau (priteau) [1] https://lists.openstack.org/pipermail/openstack-discuss/2020-October/017751…

2 3

[ovn][neutron] RE: OVN BGP Agent query
by Ihtisham ul Haq 18 Oct '22

18 Oct '22

Hi Luis and Daniel, Please see inline response. > From: Daniel Alvarez Sanchez <dalvarez(a)redhat.com> > Sent: 29 September 2022 11:37 > Subject: Re: OVN BGP Agent query > > Hi Ihtisham and Luis, > > On Thu, Sep 29, 2022 at 7:42 AM Luis Tomas Bolivar <ltomasbo(a)redhat.com> wrote: > > Some comments and questions inline > > > > On Tue, Sep 27, 2022 at 1:39 PM Ihtisham ul haq <ihtisham.uh(a)hotmail.com> wrote: > > > Hi Luis, > > > > > > Thanks for your work on the OVN BGP Agent. We are planning > > > to use it in our OVN deployment, but have a question regarding it. > > > > Great to hear! Can you share a bit more info about this environment? like > > openstack version, target workload, etc. We plan to use this with Yoga version. Our workload consist of enterprise users with VMs running on Openstack and connected to their enterprise network via transfer network(to which the customer neutron router is attached to). And we also have public workload but with the ovn-bgp we only want to we want to advertise the former. > > > > > The way our current setup with ML2/OVS works is that our customer VM IP routes > > > are announced via the router IP(of the that customer) to the leaf switch instead of > > > the IP of the host where the neutron BGP agent runs. And then even if the > > > router fails over, the IP of the router stays the same and thus the BGP route > > > doesn't need to be updated. > > > > Is this with Neutron Dynamic Routing? When you say Router IP, do you mean the virtual neutron router and its IP associated with the provider network? What type of IPs are you announcing with BGP? IPs on provider network or on tenant networks (or both)? Yes, that's with Neutron DR agent, and I meant virtual neutron router with IP from the provider network. We announce IPs of our tenant network via the virtual routers external address. > > If the router fails over, the route needs to be updated, doesn't it? Same IP, but exposed in the new location of the router? Correct. > The route to the tenant network doesn't change, ie. > 192.168.0.0 via 172.24.4.100 (this route remains the same regardless of where 172.24.4.100 is). > If there's L2 in the 172.24.4.0 network, the new location of 172.24.4.100 will be learnt via GARP announcement. In our case, this won't happen as we don't have L2 so we expose directly connected routes to overcome this "limitation". Right, in our case we have a stretched L2 transfer network(mentioned above) to which our gateway nodes and customer routers are connected to, so we can advertise the IPs from the tenant network via the virtual router external IP and thus the location of the router isn't relevant in case of failover as its address will be relearned. > In the case of Neutron Dynamic Routing, there's no assumption that everything is L3 so GARPs are needed to learn the new location. > > > > We see that the routes are announced by the ovn-bgp-agent via the host IP(GTW) in our > > > switch peers. If that's the case then how do you make sure that during failover > > > of a router, the BGP routes gets updated with the new host IP(where the router > > > failed over to)? > > > > The local FRR running at each node is in charge of exposing the IPs. For the IPs on the provider network, the traffic is directly exposed where the VMs are, without having to go through the virtual router, so a router failover won't change the route. > > In the case of VMs on tenant networks, the traffic is exposed on the node where the virtual router gateway port is associated (I suppose this is what you refer to with router IP). In the case of a failover the agent is in charge of making FRR to withdraw the exposed routes on the old node, and re-advertise them on the new router IP location > > > > > Can we accomplish the same route advertisement as our ML2/OVS setup, using the ovn-bgp-agent? > > I think this is technically possible, and perhaps you want to contribute that functionality or even help integrating the agent as a driver of Neutron Dynamic Routing? Sounds good, our plan currently is to add this to the ovn-bgp-agent, so we can announce our tenant routes via virtual routers external address on a stretched L2 network, to make it work with our use case. -- Ihtisham ul Haq Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.

3 5

[kolla] Monasca removal, Kafka and Zookeeper deprecation/removal
by Michał Nasiadka 18 Oct '22

18 Oct '22

Hello, As Kolla/Kolla-Ansible projects are implementing switch to OpenSearch - it became obvious to remove Elasticsearch (which is EOL in Kolla-provided version) and orchestrate a direct upgrade into OpenSearch. Part of this work is removal of elasticsearch and log stash Kolla container images and elasticsearch role in Kolla-Ansible. Since Monasca is relying on Elasticsearch and Logstash - and there are no contributors willing to make it work with OpenSearch inside Kolla/Kolla-Ansible - we decided to drop Monasca support in Zed release (especially that the CI jobs have been long failing). One of the Monasca dependencies is Kafka (and ZooKeeper) - is there anybody using it outside of Monasca deployment in Kolla/Kolla-Ansible? If in 4 weeks there will be no answers to this question - we will also remove Kafka and ZooKeeper container images in Kolla (and their respective roles in Kolla-Ansible). Thanks Michal

1 0