May 2021 - openstack-discuss - lists.openstack.org

[interop] patches to review
by Kanevsky, Arkady 18 May '21

18 May '21

Team, Can use a few reviews on these: https://review.opendev.org/c/osf/interop/+/784622 https://review.opendev.org/c/osf/interop/+/789399 https://review.opendev.org/c/osf/interop/+/787646 Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

[cinder] festival of XS reviews 21 April 2021
by Brian Rosmaita 18 May '21

18 May '21

Hello Cinder community members, This is a reminder that the most recent edition of the Cinder Festival of XS Reviews will be held at the end of this week on Friday 21 April. who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 21 April 2021 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews This recurring meeting can be placed on your calendar by using this handy ICS file: http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics See you there! brian

1 1

[xena][neutron][ovn] Follow up to BGP with OVN PTG discussions
by Dan Sneddon 18 May '21

18 May '21

Thank you all who attended the discussions at the Xena PTG regarding BGP dynamic routing with Neutron using OVN. Here's a brief summary of the important points covered, and some background information. Red Hat has begun gathering a team of engineers to add OpenStack support for BGP dynamic routing using the Free Range Routing (FRR) set of daemons. Acting as a technical lead for the project, I led one session in the TripleO room to discuss the installer components and two sessions in the Neutron room to discuss BGP routing with OVN, and BGP EVPN with OVN. There was some feedback during the Neutron sessions that little has been done to engage the greater OpenStack/Neutron community thus far, or to utilize the existing RFE process for Neutron. This feedback was correct and was received. Initial work was done with a design that didn't require changes on Neutron/core OVN to start with. The intention is to create Neutron RFEs and to work with others working along similar lines now that we have some more clarity as to the direction of further efforts. There will likely be opportunities to leverage APIs and contribute to existing work being done with Neutron Dynamic Routing, BGPVPN, and other work being done to implement BGP EVPN. We would like to collaborate with Ericsson and others and come up with a solution that fits us all! The first steps involved greater changes to the deployment tooling, and this was proposed and reviewed upstream in the TripleO project: _ https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/triplo-bg… There are several use cases for using BGP, and in fact there are separate efforts underway to utilize BGP for the control plane and data plane. BGP may be used for equal-cost multipath (ECMP) load balancing of outbound links, and bi-directional forwarding detection (BFD) for resiliency to ensure that a path provides connectivity. For outbound connectivity BGP will learn routes from BGP peers. There is separate work being done to add BFD support for Neutron and Neutron Dynamic Routing, but this does not provide BFD support for host communication at the hypervisor layer. Using FRR at the host level provides this BFD support. BGP may be used for advertising routes to API endpoints. In this model HAProxy will listen on an IP address and FRR will advertise routes to that IP to BGP peers. High availability for HAProxy is provided via other means such as Pacemaker, and FRR will simply advertise the virtual IP address when it is active on an API controller. BGP may also be used for routing inbound traffic to provider network IPs or floating IPs for instance connectivity. The Compute nodes will run FRR to advertise routes to the local VM IPs or floating IPs hosted on the node. FRR has a daemon named Zebra that is responsible for exchanging routes between routing daemons such as BGP and the kernel. The redistribute connected statement in the FRR configuration will cause local IP addresses on the host to be advertised via BGP. Floating IP addresses are attached to a loopback interface in a namespace, so they will be redistributed using this method. Changes to OVN will be required to ensure provider network IPs assigned to VMs will be assigned to a loopback interface in a namespace in a similar fashion. FRR was selected for integration into TripleO and OVN for several reasons: using FRR leverages a proven production-grade routing solution that gives us BGP, BFD (bi-directional forwarding detection), VRFs for different namespaces for multitenancy, integration with kernel routing, and potentially other features such as OSPF, RPKI, route monitoring/mirroring, and more. FRR has a very complete feature set and is very robust, although there are other BGP speakers available such as ExaBGP or BIRD, and os-ken, with varying feature sets. OVN will need to be modified to enable the Compute node to assign VM provider network IPs to a loopback interface inside a namespace. These IP address will not be used for sending or receiving traffic, only for redistributing routes to the IPs to BGP peers. Traffic which is sent to those IP addresses will be forwarded to the VM using OVS flows on the hypervisor. An example agent for OVN has been written to demonstrate how to monitor the southbound OVN DB and create loopback IP addresses when a VM is started on a Compute node. The OVN changes will be detailed in a separate OVN spec. Demonstration code is available on Github: _ https://github.com/luis5tb/bgp-agent BGP EVPN with multitenancy will require separate VRFs per tenant. This will allow separate routing tables to be maintained, and allow for overlapping IP addresses for different Neutron tenant networks. FRR may have the capability to utilize a single BGP peering session to combine advertisements for all these VRFs, but there is still work to be done to prototype this design. This may result in more efficient BGP dynamic updates, and could potentially make troubleshooting more straightforward. As suggested in the PTG discussions, we are investigating the BGPVPN API. It appears that this API will work well for this use case. Hopefully we can make significant progress during the Xena development cycle, and we will be able to define what needs to be done in subsequent cycles. Any thoughts, suggestions, and contributions are appreciated. If anyone would like to review the work that we've already published, there is a series of blog posts that Luis Tomas Bolivar made related to how to use it on OpenStack and how it works: - OVN-BGP agent introduction: https://ltomasbo.wordpress.com/2021/02/04/openstack-networking-with-bgp/ - How to set ip up on DevStack Environment: https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-testing-setup/ - In-depth traffic flow inspection: https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-in-depth-traffic-fl… Here are some relevant links to posts written by Luis Tomas Bolivar on the ovs-discuss mailing list: https://mail.openvswitch.org/pipermail/ovs-discuss/2021-March/051029.html https://mail.openvswitch.org/pipermail/ovs-discuss/2021-March/051031.html https://mail.openvswitch.org/pipermail/ovs-discuss/2021-March/051033.html -- Dan Sneddon | Senior Principal Software Engineer dsneddon(a)redhat.com | redhat.com/cloud dsneddon:irc | @dxs:twitter

2 1

[cinder][kolla][OSA][release] Wallaby cycle-trailing release deadline
by Herve Beraud 18 May '21

18 May '21

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Wallaby trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until July 02, 2021: https://releases.openstack.org/xena/schedule.html#x-cycle-trail <https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail> If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla openstack-ansible-roles openstack-ansible Thanks! Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[neutron]l3 vrotuer use dpdk ports making Forwarding performance too low
by yangkai 18 May '21

18 May '21

Hi,     I have a problem, when l3 vrouter use dpdk ports,  the performance is too low, eg: the bandwidth of vm's east-west. This is a aware issue? Have some solution if need l3 router and vm on one dpdk host? Best Regards, Yangkai

1 0

spice console configuration instead of vnc
by cloud learner 18 May '21

18 May '21

Dear Experts, I have installed Victoria On centos through packstack single node, i want to use spice console instead of vnc. And Installed the openstack-nova-spicehtml5proxy service and started and stop novncproxy service controller=10.1.75.20 In nova.conf [vnc] enabled=False [spice] agent_enabled = False enabled = True html5proxy_base_url = http://10.1.75.20:6082/spice_auto.html html5proxy_host = 0.0.0.0 html5proxy_port = 6082 keymap = en-us server_listen = 0.0.0.0 server_proxyclient_address = controller Above configuration made, but unable to get the spice console.. Kindly help

1 0

[neutron] Bug Deputy Report May 10 - 16th
by Oleg Bondarev 18 May '21

18 May '21

Hi everyone, Please find Bug Deputy report for the week May 10 - 16th below. Nothing Critical, just a few OVN bugs looking for triage from OVN folks (see the end of the list). Medium: - https://bugs.launchpad.net/neutron/+bug/1928345 - "neutron_tempest_plugin.api.test_trunk*" tests failing Edit o Assigned to Rodolfo Alonso o In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791255 - https://bugs.launchpad.net/neutron/+bug/1928299 - centos7 train vm live migration stops network on vm for some minutes o Unassigned o Incomplete: same issue as in https://bugs.launchpad.net/neutron/+bug/1815989 - https://bugs.launchpad.net/neutron/+bug/1928450 - ovn_migration.sh script doesn't detect neutron_dhcp agents when... o Fix released - https://bugs.launchpad.net/neutron/+bug/1928465 - Geneve allocation is not update during migration from ml2/ovs to ovn o Assigned to Jakub Libosvar o Fixed by https://review.opendev.org/c/openstack/neutron/+/784352, in progress for Wallaby - https://bugs.launchpad.net/neutron/+bug/1928466 - Allowed address pairs aren't populated to the new host with DVR router o Assigned to Slawek o In progress: https://review.opendev.org/c/openstack/neutron/+/791492 - https://bugs.launchpad.net/neutron/+bug/1927926 - Ha port is not cleared when cleanup l3router ns o Assigned to fanxiujian o Invalid Low: - https://bugs.launchpad.net/neutron/+bug/1928471 - Wrong assertion methods in unit test o Assigned to Takashi Natsume o Fix released - https://review.opendev.org/c/openstack/neutron/+/791497 Wishlist: - https://bugs.launchpad.net/neutron/+bug/1928211 - Remove quota "ConfDriver", deprecated in Liberty o Assigned to Rodolfo Alonso o In progress: https://review.opendev.org/c/openstack/neutron/+/790999 OVN Triage needed: - https://bugs.launchpad.net/neutron/+bug/1928330 - [OVN] Unable to ping router from test IPV6 subnet o Unassigned o New: OVN folks please triage - https://bugs.launchpad.net/neutron/+bug/1927977 - OVN IDLs not initialized for all worker types o Unassigned o New - https://bugs.launchpad.net/neutron/+bug/1928164 - [OVN] Ovn-controller dose not update the flows table when localport tap device is rebuilt o Unassigned o New Thanks, Oleg --- Advanced Software Technology Lab Huawei

1 0

[openstack-helm] Meeting Cancelled
by Gage Hugo 18 May '21

18 May '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow May 18th, the meeting is cancelled. Our next meeting will be May 25th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[Nova] Meeting time poll
by Artom Lifshitz 17 May '21

17 May '21

Hey all, As discussed during the IRC meeting today, the Red Hat Nova team would like to know if it's possible to shift the IRC meeting to a different day and/or time. This would facilitate our own internal calls, but I want to be very clear that we'll structure our internal calls around upstream, not the other way around. So please do not perceive any pressure to change, this is just a question :) To help us figure this out, I've created a Doodle poll [1]. I believe the regular attendees of the IRC meeting are spread between Central Europe and NA West Coast, so I've tried to list times that kinda make sense in both of those places, with a couple of hours on each side as a safety margin. Please vote on when you'd like the Nova IRC meeting to take place. Ignore the actual dates (like May 10), the important bits are the days of the week (Monday, Tuesday, etc). This is obviously a recurring meeting, something that Doodle doesn't seem to understand. I've not included Mondays and Wednesdays in the list of possibilities, as they would not work for Red Hat Nova. You can also vote to keep the status quo :) The times are listed in UTC, like the current meeting time, so unfortunately you have to be mindful of the effects of daylight savings time :( Thanks in advance! [1] https://doodle.com/poll/45ptnyn85iuw7pxz

1 2

Restart cinder-volume with Ceph rdb
by ManuParra 17 May '21

17 May '21

Dear OpenStack community, I have encountered a problem a few days ago and that is that when creating new volumes with: "openstack volume create --size 20 testmv" the volume creation status shows an error. If I go to the error log detail it indicates: "Schedule allocate volume: Could not find any available weighted backend". Indeed then I go to the cinder log and it indicates: "volume service is down - host: rbd:volumes@ceph-rbd”. I check with: "openstack volume service list” in which state are the services and I see that indeed this happens: | cinder-volume | rbd:volumes@ceph-rbd | nova | enabled | down | 2021-04-29T09:48:42.000000 | And stopped since 2021-04-29 ! I have checked Ceph (monitors,managers, osds. etc) and there are no problems with the Ceph BackEnd, everything is apparently working. This happened after an uncontrolled outage.So my question is how do I restart only cinder-volumes (I also have cinder-backup, cinder-scheduler but they are ok). Thank you very much in advance. Regards.

7 17