July 2020 - openstack-discuss - lists.openstack.org

[cyborg] Temporary treatment plan for the 3rd-party driver
by Brin Zhang(张百林) 09 Jul '20

09 Jul '20

Hi all： This release we want to introduce some 3rd party drivers (e.g. Intel QAT, Inspur FPGA, and Inspur SSD etc.) in Cyborg, and we discussed the handling of 3rd-party driver CI in Cyborg IRC meeting [1]. Due to the lack of CI test environment supported by hardware, we reached a temporary solution in two ways, as follows: 1. Provide a CI environment and provide a tempest test for Cyborg, this method is recommended; 2. If there is no CI environment, please provide the test results of this driver in the master branch or in the designated branch, which should be as complete as possible, sent to the Cyborg team, or pasted in the implementation of the commit. [1] http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyb…

1 0

RDO - ModuleNotFoundError: No module named 'cinder.volume.drivers.glusterfs'
by lejeczek 09 Jul '20

09 Jul '20

Hi guys, I've packstaked a deployment with: CONFIG_CINDER_BACKEND=gluster CONFIG_CINDER_VOLUMES_CREATE=y CONFIG_CINDER_GLUSTER_MOUNTS=127.0.0.1:/VMs But after seemingly all work okey I keep getting: 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume Traceback (most recent call last): 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/cmd/volume.py", line 103, in _launch_service 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume cluster=cluster) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/service.py", line 400, in create 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume cluster=cluster, **kwargs) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/service.py", line 155, in __init__ 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume *args, **kwargs) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/volume/manager.py", line 267, in __init__ 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume active_backend_id=curr_active_backend_id) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/oslo_utils/importutils.py", line 44, in import_object 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume return import_class(import_str)(*args, **kwargs) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/oslo_utils/importutils.py", line 30, in import_class 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume __import__(mod_str) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume ModuleNotFoundError: No module named 'cinder.volume.drivers.glusterfs' 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume ... I'm Centos 8 with "ussuri". Would you know & share a solution? many thanks, L.

3 2

[kolla] Today is the first Kall
by Radosław Piliszek 09 Jul '20

09 Jul '20

Hiya Folks, today (09 Jul) is the first Kolla's Kall [1]. It starts at 15:00 UTC so in just a bit less than half an hour. (Sorry for the late reminder, these days don't spare me.) Today's agenda is based on one of the top priorities for Victoria - DA DOCS. We decided to give Meetpad a try. It does not record meetings but we will document the meeting on etherpad anyhow. The link is on the referenced wiki page. (The potential fallback will be Google Meet, we will update the wiki). Everyone is free to join. Kolla Kall is development-oriented and focuses on implementation discussion, change planning, release planning, housekeeping, etc. The expected audience is people interested in Kolla projects development, including Kolla, Kolla-Ansible and Kayobe. Looking forward to seeing YOU there. [1] https://wiki.openstack.org/wiki/Meetings/Kolla/Kall -yoctozepto

1 1

Hardware requirement for OpenStack HA Cluster
by Anil Jangam 09 Jul '20

09 Jul '20

Hi All, I am looking for hardware requirements (CPU, RAM, HDD) for installing a OpenStack HA cluster. So far, I gathered few references: - This article talks about CPU and HDD, but they do not comment on RAM. - https://docs.openstack.org/project-deploy-guide/openstack-ansible/ocata/ove… - This article talks about CPU, RAM, and HDD, but it is quite old (2015) reference. - https://docs.huihoo.com/openstack/docs.openstack.org/ha-guide/HAGuide.pdf (Page 6) I am considering the cluster with: 3 Controller (for HA) + 1 Compute + 1 Storage. I have following questions: - What is the minimum hardware (CPU, RAM, HDD) requirement to install a OpenStack HA cluster? - Can we have 3 Controller nodes installed on 3 Virtual Machines or do we need 3 independent (bare metal) servers? - So in case of VM-based controllers, the cluster will be hybrid in nature. - I do not know if this is even possible and a recommended design. - Do we need the Platform Director node in addition to controller and compute/storage nodes? Thanks in advance. Anil.

2 1

[All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change. OVN in 75 Words --------------- Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB. Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5] Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository. Why? ---- In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration. What Does it Mean? ------------------ Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now. Action Plan ----------- We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below: 1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a. [1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13… [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/ -- Slawek Kaplonski Senior software engineer Red Hat

6 8

[neutron] Drivers meeting - agenda for 10.07.2020
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, For tomorrow’s meeting we have 2 RFEs to discuss: https://bugs.launchpad.net/neutron/+bug/1886798 - [RFE] Port NUMA affinity policy - this one was already discussed briefly few weeks ago - see http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_driver… - but now as Rodolfo proposed official RFE, lets talk again about it, https://bugs.launchpad.net/neutron/+bug/1880532 - [RFE]L3 Router should support ECMP - this one was also discussed some time ago, owner of the rfe provided some additional info recently so please take a look into that and we will also discuss that tomorrow. Have a great day and see You on tomorrow’s meeting :) — Slawek Kaplonski Principal software engineer Red Hat

1 0

[neutron] PTL on vacation
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, For the next 2 weeks, starting Saturday 11th of July I will be on vacation without access to the irc and with very limited access to the email. Miguel Lavalle will run our team meetings during this time. With other things You can always ask one of our drivers [1] or lieutenants [1] https://review.opendev.org/#/admin/groups/464,members [2] https://docs.openstack.org/neutron/latest/contributor/policies/neutron-team… — Slawek Kaplonski Principal software engineer Red Hat

1 0

[Cinder]
by Marek Lyčka 09 Jul '20

09 Jul '20

Hi all, I'm currently looking into extending Nova API to allow on-demand VM quiescing with the ultimate goal being improved Cinder snapshot creation. The spec is undergoing review at the moment and I was wondering if someone from Cinder would be kind enough to look it over and give their thoughts on it: https://review.opendev.org/#/c/702810/ Thanks in advance. -- Marek Lyčka Linux Developer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic marek.lycka(a)ultimum.io <stanislav.ulrych(a)ultimum.io> *https://ultimum.io <https://ultimum.io/>*

2 1

July OSF Community Meeting - 10 Years of OpenStack
by Sunny Cai 08 Jul '20

08 Jul '20

Hello everyone, You might have heard that OpenStack is turning 10 this year! On Thursday, July 16 at 8am PT (1500 UTC), we will be holding the 10 years of OpenStack virtual celebration in the July OSF community meeting. I have attached the calendar invite for the July OSF community meeting below. Grab your favorite OpenStack swag and bring your favorite drinks of choice to the meeting on July 16. Let’s do a virtual toast to the 10 incredible years! Please see the etherpad for more meeting information: https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV <https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV> If you have any questions, please let me know. P.S. To add more fun, feel free to try out the virtual background feature in Zoom. The 10 years of OpenStack virtual background is attached below. Thanks, Sunny Cai OpenStack Foundation sunny(a)openstack.org <mailto:sunny@openstack.org>

1 0

[neutron][lbaas][octavia] How to implement health check using 100.64.0.0/10 network segments in loadbalancer?
by Zhengyu Pan 08 Jul '20

08 Jul '20

There are some private cloud or public cloud introduction: They use 100.64.0.0/14 network segments to check vm's health status in load balancer. In Region supporting VPC, load balancing private network IP and health check IP will be switched to 100 network segment. I can't understand how to implement it. How to do it? --

2 1