May 2020 - openstack-discuss - lists.openstack.org

[Octavia] Help with bridge interfaces with openstack queens in a existing neutron openvswitch dvr snat environment
by Bujack, Stefan 05 May '20

05 May '20

Hello, I am trying to install octavia in our existing Openstack Queens Cloud and have problems with the lb-mgmt network ports. Is there anybody who could please help me with this issue? Thanks in advance, Greets Stefan Bujack

2 1

[puppet] Configuring Debian's uwsgi for each service
by Thomas Goirand 05 May '20

05 May '20

Hi, In Debian all service APIs are by default using uwsgi. This means that there's no reason to setup Apache for the API, as uwsgi comes by default. However, there are a number of things that operators may want to configure, like for example, the number of workers. This is why I started this PR: https://review.opendev.org/725065 Since Tobias asked for more details about what I was doing, I thought it was a good idea to start a thread in the list, rather than just discussing in the patch review. So, what I did for Neutron is only the beginning. If it works as I expect, I intend to generalize this on all OpenStack services supported by Debian. This means at least: - nova - keystone - glance - cinder - barbican - neutron - aodh - panko - gnocchi - etc. The first step is having this neutron_uwsgi_config provider up and running, then I'll see how to integrate with the rest of puppet-openstack and have things like number of workers integrated with <SERVICE>::api stuff... Your thoughts? Cheers, Thomas Goirand (zigo)

4 6

[openstack-ansible] dropping suse support
by Mohammed Naser 05 May '20

05 May '20

Hi everyone, I've been trying to avoid writing this email for the longest time ever. It's really painful to have to reach this state, but I think we've hit a point where we can no longer maintain support for SUSE within OpenStack Ansible. Unfortunately, with the recent layoffs, the OSA team has taken a huge hit in terms of contributors which means that there is far less contributors within the project. This means that we have less resources to go around and it forces us to focus on a more functional, reliable and well tested set of scenarios. Over the past few cycles, there has been effort to add SUSE support to OpenStack Ansible, during the time that we had maintainers, it was great and SUSE issues were being fixed promptly. In addition, due to the larger team at the time, we found ourselves having some extra time where we can help unbreak other gates. Jesse used to call this a "labour of love", which I admired at the time and hoped we continue to do as much as we can of. However, the lack of a committed maintainer for OpenSUSE has resulted in constantly failing jobs[1][2] (which were moved to non-voting, wasting CI resources as no one fixed them). In addition, it's causing several gate blocks for a few times with no one really finding the time to clean them up. We are resource constrained at this point and we need the resource to go towards making the small subset of supported features functional (i.e. CentOS/Ubuntu). We struggle with that enough, and there seems to be no deployers that are running SUSE in real life at the moment based on bugs submitted. With that, I propose that we drop SUSE support this cycle. If anyone would like to volunteer to maintain it, we can review that option, but that would require a serious commitment as we've had maintainers step off and it hurts the velocity of the project as no one can merge code anymore. ..Really wish I didn't have to write this email Mohammed [1]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct… [2]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…

6 9

[all][qa] grenade zuulv3 native job available now and its migration plan
by Ghanshyam Mann 05 May '20

05 May '20

Hello Everyone, Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch. Thanks to tosky for keep working on this and finish it!! New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'. * Start using this new base job for your projects specific grenade jobs. * Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri). Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also. [1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/ -gmann

7 14

[tripleo] Container image tooling roadmap
by Kevin Carter 05 May '20

05 May '20

Hello Stackers, As you may have seen, the TripleO project has been testing the idea of building container images using a simplified toolchain [0]. The idea is to build smaller, more easily maintained images to simplify the lives of TripleO consumers. Since TripleO's move to containers, the project has been leveraging Kolla to provide Dockerfiles, and while this has worked, TripleO has created considerable tooling to bend Kolla images to its needs. Sadly this has resulted in an image size explosion and the proliferation of difficult to maintain tools, with low bus factors, which are essential to the success of the project. To address the risk centered around the TripleO containerization story, we've drafted a spec [0], which we believe outlines a more sustainable future. In this specification, we've designed a new, much more straightforward, approach to building container images for the TripleO project. The "simple container generation," specification does not intend to be a general-purpose tool used to create images for the greater OpenStack community, both Loci and Kolla do that already. This effort is to build containers only for TripleO using distro provided repositories, with distro maintained tooling. By focusing only on what we need, we're able to remove all general-purpose assumptions and create a vertically integrated stack resulting in a much smaller surface area. To highlight how all this works, we've put together several POC changes: * Role and playbook to implement the Containerfile specification [1]. * Tripleoclient review to interface with the new role and playbook [2]. * Directory structure for variable file layout [3]. * To see how this works using the POC code, building images we've tested in real deployments, please watch the ASCII-cast [4]. * Example configuration file examples are here [5][6][7]. A few examples of size comparisons between our proposed tooling versus current Kolla based images [8]: - base: + Kolla: 588 MB - new: 211 MB # based on ubi8, smaller than centos8 - nova-base: + Kolla: 1.09 GB - new: 720 MB - nova-libvirt: + Kolla: 2.14 GB - new: 1.9 GB - keystone: + Kolla: 973 MB - new: 532 MB - memcached: + Kolla: 633 MB - new: 379 MB While the links shown are many, the actual volume of the proposed change is small, although the impact is massive: * With more straightforward to understand tools, we'll be able to get broader participation from the TripleO community to maintain our containerization efforts and extend our service capabilities. * With smaller images, the TripleO community will serve OpenStack deployers and operators better; less bandwidth consumption and faster install times. We're looking to chart a more reliable path forward, and making the TripleO user experience a great one. While the POC changes are feature-complete and functional, more work is needed to create the required variable files; however, should the proposed specification be ratified, we expect to make quick work of what's left. As such, if you would like to be involved or have any feedback on anything presented here, please don't hesitate to reach out. We aim to provide regular updates regarding our progress on the "Simple container generation" initiative, so stay tuned. Thanks, Kevin and Emilien [0] https://review.opendev.org/#/c/723665/ [1] https://review.opendev.org/#/c/722557/ [2] https://review.opendev.org/#/c/724147/ [3] https://review.opendev.org/#/c/722486/ [4] https://files.macchi.pro:8443/demo-container-images/ [5] http://paste.openstack.org/show/792995/ [6] http://paste.openstack.org/show/792994/ [7] http://paste.openstack.org/show/792993/ [8] https://4ce3fa2efa42bb6b3a69-771991cd07d409aaec3e4ca5eafdd7e0.ssl.cf2.rackc… Kevin Carter IRC: kecarter

11 27

[blazar] Updating blazar-core and blazar-release groups
by Pierre Riteau 05 May '20

05 May '20

Hello, I noticed in a recent blazar-specs patch [1] that lots of historical contributors were requested as reviewers. I assume this is because the blazar-core group was used (this is not a feature that I've used before on Gerrit). To avoid spamming people who haven't worked on Blazar for years, I propose to remove the following members of the blazar-core group: Dina Belova Hiroaki Kobayashi Nikolay Starodubtsev Pablo Andres Fuente Ryota MIBU Swann Croiset Sylvain Bauza I would also remove Hiroaki Kobayashi from the blazar-release group. Please let me know if you have any objections. [1] https://review.opendev.org/#/c/723115/

2 2

[neutron] bug deputy report (4/27-5/3)
by Akihiro Motoki 05 May '20

05 May '20

Hi, I was a bug deputy last week. The last week was relatively a quiet week. Higher priority bugs have assignees. They are not release blockers, while it is nice to have them backported. A bug on DVR with flat network needs to be covered by L3 team. ## Untriaged * https://bugs.launchpad.net/neutron/+bug/1876092 DVR with Flat network result in ICMP reply DUP New, Undecided It needs to be checked by DVR folks. I am not sure DVR with flat network is not supported by design or it is just a bug. * https://bugs.launchpad.net/neutron/+bug/1876021 create multiple reserved_dhcp_port doesn't work as expected I will try to reproduce it after the holiday week in my side is over. ## Assigned * https://bugs.launchpad.net/neutron/+bug/1875849 not ensure default security group exists when filter by project_id Medium, In Progress, the reporter is working on the fix ## In Progress * https://bugs.launchpad.net/nova/+bug/1863021 eventlet monkey patch results in assert `len(_active) == 1` AssertionError High, In Progress, a fixed is in the gate * https://bugs.launchpad.net/neutron/+bug/1876148 OVNL3RouterPlugin should add_router_interface as in RouterPluginBase Medium, In Progress * https://bugs.launchpad.net/neutron/+bug/1876094 Dnsmasq 2.81 broke neutron's DHCP service High, In Progress ## New RFEs * https://bugs.launchpad.net/neutron/+bug/1875516 [RFE] Allow sharing security groups as read-only will be discussed in coming drivers meetings * https://bugs.launchpad.net/neutron/+bug/1875852 [RFE] [OVN] SRIOV routing on VLAN Tenant networks ## Fix Released * https://bugs.launchpad.net/neutron/+bug/1875865 SRIOV OVN metadata namespaces not cleaned up after ports are unbounded * https://bugs.launchpad.net/bugs/1875344 Cleanup in neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON may fail in dvr deployments

1 0

[all][docs] docs.openstack.org: Check Ussuri Index pages
by Andreas Jaeger 05 May '20

05 May '20

The Ussuri index pages [1] are now published, the default on docs.o.o to Ussuri will change with release. The index pages only list entries that existed yesterday, so if a project was branched but did not merge any change, then no Ussuri content might exist and thus the project is not listed in the index pages. In such a case: Merge the usual bot updates, wait for the content to be published, and then propose a change to [3]. For details see [2]. Andreas [1] https://docs.openstack.org/ussuri/ [2] https://docs.openstack.org/doc-contrib-guide/doc-index.html [3] https://opendev.org/openstack/openstack-manuals/src/branch/master/www/proje… -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[Watcher] No IRC meeting tomorrow
by licanwei 05 May '20

05 May '20

1 0

[ironic][ptg] Virtual PTG - Victoria
by Iury Gregory 05 May '20

05 May '20

Hello Ironicers! We need to choose the slots for the Virtual PTG[1] on the official schedule [2]. So, if you are interested in participating you need to do two things: 1- Add your name and topics to the etherpad [3]. 2- Fill out the doodle in [4]. Thank you! [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/Ironic-VictoriaPTG-Planning [4] https://doodle.com/poll/mbpr2x7z3t5hqec6 -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 2