November 2020 - openstack-discuss

[docs] HTTP redirects
by Peter Matulis 18 Nov '20

18 Nov '20

Hi, So I followed instructions [1] to implement redirects and it's not working. Please let me know where I went wrong: https://review.opendev.org/#/c/763067/ Shouldn't the first URL redirect to the second? https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/late… https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/late… Thanks, Peter [1]: https://docs.openstack.org/doc-contrib-guide/redirects.html

3 2

[Victoria][Python-3.9] dhcp-agent problem
by tjoen 17 Nov '20

17 Nov '20

System: LFS. Python-3.9.0, Neutron-17.0.0, oslo.privsep-2.4.0 Got Train+Py37, Usuri+Py38 working with the help of the install-guide. Victoria+Py39 Only eventlet needed a patch. Neutron only for neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py def ebtables(comm, table='nat'): execute = ip_lib.IPWrapper(NAMESPACE).netns.execute - return execute(['ebtables', '-t', table, '--concurrent'] + comm, + return execute(['/usr/sbin/ebtables', '-t', table, '--concurrent'] + comm, run_as_root=True) Possible not necessary but it avoids sudo errors. Controller logs (made readable): [-] Unable to enable dhcp for cb7948eb-e5c0-4764-a653-542c3e864f54.: TypeError: <lambda>() takes 6 positional arguments but 7 were given Traceback (most recent call last): File "/site-packages/neutron/agent/dhcp/agent.py", line 192, in call_driver rv = getattr(driver, action)(**action_kwargs) File "/site-packages/neutron/agent/linux/dhcp.py", line 249, in enable common_utils.wait_until_true(self._enable, timeout=300) File "/site-packages/neutron/common/utils.py", line 703, in wait_until_true while not predicate(): File "/site-packages/neutron/agent/linux/dhcp.py", line 261, in _enable interface_name = self.device_manager.setup(self.network) File "/site-packages/neutron/agent/linux/dhcp.py", line 1675, in setup if ip_lib.ensure_device_is_ready(interface_name, File "/site-packages/neutron/agent/linux/ip_lib.py", line 960, in ensure_device_is_ready if not dev.link.exists or not dev.link.address: File "/site-packages/neutron/agent/linux/ip_lib.py", line 513, in exists return privileged.interface_exists(self.name, self._parent.namespace) File "/site-packages/oslo_privsep/priv_context.py", line 247, in _wrap return self.channel.remote_call(name, args, kwargs) File "/site-packages/oslo_privsep/daemon.py", line 224, in remote_call raise exc_type(*result[2]) TypeError: <lambda>() takes 6 positional arguments but 7 were given Launching an instance: $ openstack server create --flavor m1.nano --image cirros \ --nic net-id=cb7948eb-e5c0-4764-a653-542c3e864f54 --security-group default \ --key-name mykey provider-instance results in status=BUILD and never ACTIVE Other logs on Controller after starting Compute1: Unable to access /var/lib/neutron/dhcp/cb7948eb-e5c0-4764-a653-542c3e864f54/pid; Error: [Errno 2] No such file or directory Ownerships and permissions are OK: drwxr-xr-x 2 neutron neutron 4096 Nov 15 19:49 cb7948eb-e5c0-4764-a653-542c3e864f54/ Anybody with the same problem? I am not a Python programmer so I am at a lost

3 5

[release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro
by Radosław Piliszek 17 Nov '20

17 Nov '20

I did not quote the original subject because it was too long. It was: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed Particularly, we are continuing the discussion from: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018743… Would it be possible what Hervé is proposing? I.e. better segregation of distro per branch of release? I believe it would be a rare situation but surely testing something on Bionic and trying to release on Focal might have its quirks. -yoctozepto

4 4

[release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed
by Herve Beraud 17 Nov '20

17 Nov '20

During the release job for: - masakari-monitors 9.0.1 (ussuri) - masakari-monitors 8.0.2 (train) - masakari-monitors 7.0.1 (stein) uploads to PyPI failed [1][2][3] with: "No package matching 'python-libvirt' is available" [4][5][6] It's due to our recent move to focal [7] where the package 'python-libvirt' is named ''python3-libvirt'.This package is pulled by bindep during the job execution. Current status: Tag (9.0.1, 8.0.2, 7.0.1) was pushed OK No tarball upload No PyPI upload Once the issue is fixed, a new version should be released for the three stables branches. Version 9.0.1, 8.0.2, 7.0.1 these versions will never be uploaded on PyPi as the fix requires new changes in the project repo [8][9][10]. Also notice that on Victoria and Wallaby this bindep requirement have been dropped during the migration testing on ubuntu focal [11]. [1] https://zuul.opendev.org/t/openstack/build/63539177d44b4ea48d3fbfe39a638275… [2] https://zuul.opendev.org/t/openstack/build/778ace86ec8f4ef894d740d81e8f700f… [3] https://zuul.opendev.org/t/openstack/build/919cfc7df1e0408e9d6af4a9e8ef28ee… [4] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001… [5] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001… [6] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001… [7] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018585… [8] https://opendev.org/openstack/masakari-monitors/src/branch/stable/stein/bin… [9] https://opendev.org/openstack/masakari-monitors/src/branch/stable/train/bin… [10] https://opendev.org/openstack/masakari-monitors/src/branch/stable/ussuri/bi… [11] https://opendev.org/openstack/masakari-monitors/commit/03ef3555888fdd0ea38b… -- 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-----

3 9

[tc] weekly update
by Mohammed Naser 17 Nov '20

17 Nov '20

Hi everyone, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Add Magpie charm to OpenStack charms https://review.opendev.org/762820 - Move Placement under Nova's governance https://review.opendev.org/760917 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/759904 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/761975 - Add election schedule exceptions in charter https://review.opendev.org/751941 - Clarify the requirements for supports-api-interoperability https://review.opendev.org/760562 - Propose Kendall Nelson for vice chair https://review.opendev.org/762014 ## General Changes - Select JSON to YAML goal for Wallaby cycle https://review.opendev.org/760957 - Adding reno and warnings example for JSON->YAML goal doc https://review.opendev.org/760956 - Add danms liaison preferences https://review.opendev.org/758822 - Add goal for migrate RBAC policy format from JSON to YAML https://review.opendev.org/759881 - Add diablo_rojo liaison preferences https://review.opendev.org/759718 - Add ricolin liaison preferences https://review.opendev.org/759704 - Add gmann liaison preference https://review.opendev.org/758602 - Resetting projects' TC liaisons empty https://review.opendev.org/758600 Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[Freezer] Gerrit breach and commit audit
by caihui_nj＠163.com 17 Nov '20

17 Nov '20

1 0

[neutron] Team meetings today
by Slawek Kaplonski 17 Nov '20

17 Nov '20

Hi, Just a quick reminder that we have neutron team meeting today at 14:00 UTC and neutron CI meeting at 15:00 UTC. Both are on the #openstack-meetings-3 channel. Agenda for the meetings: https://wiki.openstack.org/wiki/Network/Meetings https://etherpad.opendev.org/p/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Freezer] Gerrit breach and commit audit
by caihui_nj＠163.com 17 Nov '20

17 Nov '20

1 0

[infra][kolla] Docker registry pull limits
by Radosław Piliszek 17 Nov '20

17 Nov '20

Hello Everyone, Kolla CI jobs started getting hit by Docker registry pull limits: docker.errors.APIError: 500 Server Error: Internal Server Error ("toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit") It is relatively random as the limit is seemingly per IP address. The question is how we should approach this issue. It seems Docker offers an open source plan that would lift any limits on the kolla namespace. [1] However, we are not entirely sure who should fill out the related form [2]. We believe it should be someone from the infra team but it is not clear. :/ Please share your thoughts. [1] https://www.docker.com/blog/expanded-support-for-open-source-software-proje… [2] https://docs.google.com/forms/d/e/1FAIpQLSd11DjfgeaKSRdqp6Br85MzQQuM4igt-xm… -yoctozepto

1 0

[manila][OSC] Priorities for implementing the OSC share commands
by Maari Tamm 17 Nov '20

17 Nov '20

Hi Everyone! Slowly but steady we are implementing the OpenStack Client for Manila. For the upcoming release we are aiming to implement the following commands, in no particular order: Share Replicas: openstack share replica create / delete / list / show / set / promote / resync Share Replica Export Locations: openstack share replica export location list / show Share Manage/Unmanage: openstack share adopt / abandon Services: openstack share service set / list Share Pools: openstack share pool list User Messages: openstack share message delete / list / show Availability Zones (add support for manila): openstack availability zone list Limits (add support for manila): openstack limits show —absolute /—rate Share Export Locations (ready for reviews: https://review.opendev.org/#/c/761661/ <https://review.opendev.org/#/c/761661/>): openstack share export location list / show Share Snapshots patch II (ready for reviews: https://review.opendev.org/#/c/746458/ <https://review.opendev.org/#/c/746458/>) : openstack share snapshot adopt / abandon openstack share snapshot export location show / list openstack share snapshot access create / delete / list To make this happen we could really use help reviewing the patches, once proposed. As linked above, two patches are currently ready for testing/reviews. We’d also very much appreciate getting some feedback on the list itself. Are we missing something important that would be useful for operators and should be implemented this cycle? If anyone has some commands in mind, please do let us know! Mohammed Naser and Belmiro Moreira, would love to get your thoughts on this as well! :) Thanks, Maari Tamm (IRC: maaritamm)

2 1

[Heat] Fwaas v2 support
by Yves Gd 17 Nov '20

17 Nov '20

Hi, Trying to use a HOT firewall template, I encounter this error: "ERROR: HEAT-E99001 Service neutron is not available for resource type OS::Neutron::Firewall, reason: Required extension fwaas in neutron service is not available." We use fwaas v2, is it supported by heat module on Train version? Our openstack environment is deployed by kolla (9.2.0) with fwaas enabled. I assume "yes" but would like to be sure. Sorry if it's written somewhere but I couldn't find this information. Here is a simple version producing the error: ------------------- heat_template_version: rocky resources: firewall1: type: OS::Neutron::Firewall properties: description: Test fwaas name: Test_fwaas ------------------- Regards, Yves

3 2

[tacker] Skip IRC meeting on Nov 17th
by Yasufumi Ogawa 17 Nov '20

17 Nov '20

Hi tacker team, I am not available to join IRC meeting today. I'd like to cancel the meeting because we may have no topics, the problem of functional test has resolved and no urgent patches. Thanks, Yasufumi

1 0

[neutron] Mixed VLAN / VxLAN Network
by DHilsbos＠performair.com 17 Nov '20

17 Nov '20

All; We're getting ready to set up an OpenStack cloud, and I have some questions about networking. I apologize if this information if available already or if a question like this has already been asked. We intend to slot it in to a location which uses VLANs heavily. In particular, our DMZ is on a VLAN, with the subnet's gateway at our firewall. We plan to use VxLANs within OpenStack. Is it possible to make OpenStack aware of the DMZ VLAN, so that we can use it in projects? Is it possible to use the DMZ VLAN without routing through the OpenStack network node(s)? Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 2

[SDK][OSC] Meeting Times
by Kendall Nelson 16 Nov '20

16 Nov '20

Hello! In the PTG session today we talked about doing some sort of regular meetings to kind of jump start things after the more recent lack of activity. We discussed beginning with more frequent meetings (a couple across the next few weeks) and then shifting to a more relaxed monthly cadence. I propose 15:00 UTC on the third thursday of each month as our monthly meeting time? If people agree, I will propose a patch :) As for the more frequent ones to keep the momentum from discussion from this week/last week. We could use that time (15 UTC) and date (Thursdays) and maybe just do them on Nov 12 and 19th to keep us moving? That gives us next week to catch up/ take a breath from the last two weeks, but not waiting till after the US Thanksgiving holiday. Let me know what you think! -Kendall Nelson (diablo_rojo)

4 6

[trove] Gerrit breach and commit audit
by Lingxian Kong 16 Nov '20

16 Nov '20

Background: http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html Looking back at the patches merged between 2020-10-01 and 2020-10-20, I can confirm that the trove deliverables repos look OK. --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz

1 0

Re: Trove backup issue (Victoria)
by Lingxian Kong 16 Nov '20

16 Nov '20

(adding openstack-discuss mailing list) Hi Justin, I don't think there is a backup docker image named "openstacktrove/db-backup-mysql5.0", the backup image only support 8.0 and 5.7. You can try "openstacktrove/db-backup-mysql5.7". --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz On Tue, Nov 17, 2020 at 3:26 AM Justin Anstes <janstes(a)gmail.com> wrote: > Hi, > > Apologies to contact you about this issue. I'm sure it's a simple fix but > I've not been able to find much on it. > > I'm testing the current Victoria release. All setup ok just that I'm not > able to backup to Swift, with the following error: > > 404 Client Error: Not Found ("pull access denied for > openstacktrove/db-backup-mysql5.0, repository does not exist or may require > \'docker login\': denied: requested access to the resource is denied") > > It appears to require a Docker login.I've attached the full log just in > case you might need it. Many thanks if you have time to check. > > Kind regards > > Justin >

1 0

[qa][policy] Testing strategy discussion for new RBAC (new scope and default role combinations)
by Ghanshyam Mann 16 Nov '20

16 Nov '20

Hello Everyone, To continue the discussion on how projects should test the new RBAC (scope as well as the new defaults combination), we will host a call on bluejeans on Tuesday 10th Nov 16.00 UTC. Lance has set up the room for that: https://bluejeans.com/749897818 Feel free to join if you are interested in that or would like to help with this effort. -gmann

2 2

[ironic] Review session for API JSON conversion
by Steve Baker 16 Nov '20

16 Nov '20

Due to timezones and the nature of the change series, we're doing some group scheduled review sessions of this series which converts the WSME based REST API to a JSON: https://review.opendev.org/#/q/status:open+topic:story/1651346 Discussion can happen on IRC in #ironic. The first session will be on this Tuesday, 7pm UTC, with a follow-up on Wednesday, 8am UTC. There is a calendar invite which I can add you to on request. cheers

1 0

[monasca] Predictive Analytics
by Giacomo Lanciano 16 Nov '20

16 Nov '20

Hi all, I am new to this community, as I have only recently started using OpenStack in my research. I am working on designing an "intelligent" auto-scaling mechanism, based on resources consumption metrics forecasts, leveraging on Monasca for metrics ingestion and processing. Digging into the Wiki/Documentation, I have stumbled upon the recently retired "monasca-analytics", that seems to cover pretty much (and way more of) what I had in mind to build on top of the monitoring component, to enable proactive auto-scaling decisions. I am very interested in knowing more about why such project has been abandoned and, more importantly, whether the effort has been redirected to another project that I am not aware of. Could you point me to any resource that you consider useful to contribute on these topics? Thanks in advance. Kind Regards. Giacomo -- Giacomo Lanciano Ph.D. Student in Data Science Scuola Normale Superiore, Pisa, Italy https://www.linkedin.com/in/giacomolanciano

2 1

centos-7 infra mirror issues, lp 1904418
by Wesley Hayutin 16 Nov '20

16 Nov '20

Greetings, Just wanted to raise awareness of the following bug https://bugs.launchpad.net/tripleo/+bug/1904418 http://mirror.centos.org/centos/7/rt/x86_64/repodata/repomd.xml is a 404 Thank you!

1 0

RE: Fwd: freezer
by Cyrille CARTIER 16 Nov '20

16 Nov '20

Hi Ali, Last week I’ve got a response in StoryBoard, thanks to Carl : « The bug is fixed in victoria, please update new version. Thanks. » My Colleague confirm that Ussuri version still have the same problem. Is it good for you with Stein ? We're going to test the Victoria version soon, I'll get back to you if it works. Thanks, Cyrille De : Ali Ebrahimpour [mailto:ali74.ebrahimpour@gmail.com] Envoyé : samedi 7 novembre 2020 08:06 À : Cyrille CARTIER <Cyrille.CARTIER(a)antemeta.fr>; smooney(a)redhat.com Objet : Re: Fwd: freezer hi Cyrille,sean thank you for attention I have this problem by requesting a backup with nova i used the ussuri version and two days ago got pull the version by opendev and had not changed and I want to try to install the Stein version with python2. Maybe it works correctly Did you find a solution for versions with python3? On Fri, Nov 6, 2020 at 12:08 PM Cyrille CARTIER <Cyrille.CARTIER(a)antemeta.fr<mailto:Cyrille.CARTIER@antemeta.fr>> wrote: Hi Ali, Which openstack version do you use ? I have a similar problem on my Train plateform (deployed by kolla-ansible), using freezer-scheduler. There are many commit for py3 correction for Ussuri and Victoria branch, in Git repository [1]. Did you try these version? I have already post the problem on StoryBoard [2] and Launchpad [3]. -----Message d'origine----- Objet : Re: Fwd: freezer On Thu, 2020-11-05 at 12:42 +0330, Ali Ebrahimpour wrote: > hi i recently install the freezer api and i have problem with using it > if run this command: > freezer-agent --debug --action backup --nova-inst-id > a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container > /tmp/ali --backup-name test --mode nova --engine nova > --no-incremental true > --log-file a.log --consistency-check > > and freezer api doesn't work current and error with: > Engine error: a bytes-like object is required, not 'str' > Engine error: Forced stop that looks like a python 3 issue im not sure how active it still is but it looks like its an issue between text string and byte strings > > Adn attach the log > please help me ! > > thank you for attention [1]: https://opendev.org/openstack/freezer [2]: https://storyboard.openstack.org/#!/project/openstack/freezer [3]: https://bugs.launchpad.net/freezer/+bug/1901179 Cyrille

1 0

Victoria RDO Release Announcement
by Amy Marrich 16 Nov '20

16 Nov '20

If you're having trouble with the formatting, this release announcement is available online https://blogs.rdoproject.org/2020/11/rdo-victoria-released/ --- RDO Victoria Released The RDO community is pleased to announce the general availability of the RDO build for OpenStack Victoria for RPM-based distributions, CentOS Linux and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Victoria is the 22nd release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8/cloud/x86_64/openstack-victoria/. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. PLEASE NOTE: RDO Victoria provides packages for CentOS8 and python 3 only. Please use the Train release, for CentOS7 and python 2.7. Interesting things in the Victoria release include: - With the Victoria release, source tarballs are validated using the upstream GPG signature. This certifies that the source is identical to what is released upstream and ensures the integrity of the packaged source code. - With the Victoria release, openvswitch/ovn are not shipped as part of RDO. Instead RDO relies on builds from the CentOS NFV SIG. - Some new packages have been added to RDO during the Victoria release: - ansible-collections-openstack: This package includes OpenStack modules and plugins which are supported by the OpenStack community to help with the management of OpenStack infrastructure. - ansible-tripleo-ipa-server: This package contains Ansible for configuring the FreeIPA server for TripleO. - python-ibmcclient: This package contains the python library to communicate with HUAWEI iBMC based systems. - puppet-powerflex: This package contains the puppet module needed to deploy PowerFlex with TripleO. - The following packages have been retired from the RDO OpenStack distribution in the Victoria release: - The Congress project, an open policy framework for the cloud, has been retired upstream and from the RDO project in the Victoria release. - neutron-fwaas, the Firewall as a Service driver for neutron, is no longer maintained and has been removed from RDO. Other highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/victoria/highlights. Contributors During the Victoria cycle, we saw the following new RDO contributors: Amy Marrich (spotz) Daniel Pawlik Douglas Mendizábal Lance Bragstad Martin Chacon Piza Paul Leimer Pooja Jadhav Qianbiao NG Rajini Karthik Sandeep Yadav Sergii Golovatiuk Steve Baker Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 58 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: Adam Kimball Ade Lee Alan Pevec Alex Schultz Alfredo Moralejo Amol Kahat Amy Marrich (spotz) Arx Cruz Bhagyashri Shewale Bogdan Dobrelya Cédric Jeanneret Chandan Kumar Damien Ciabrini Daniel Pawlik Dmitry Tantsur Douglas Mendizábal Emilien Macchi Eric Harney Francesco Pantano Gabriele Cerami Gael Chamoulaud Gorka Eguileor Grzegorz Grasza Harald Jensås Iury Gregory Melo Ferreira Jakub Libosvar Javier Pena Joel Capitao Jon Schlueter Lance Bragstad Lon Hohberger Luigi Toscano Marios Andreou Martin Chacon Piza Mathieu Bultel Matthias Runge Michele Baldessari Mike Turek Nicolas Hicher Paul Leimer Pooja Jadhav Qianbiao.NG Rabi Mishra Rafael Folco Rain Leander Rajini Karthik Riccardo Pittau Ronelle Landy Sagi Shnaidman Sandeep Yadav Sergii Golovatiuk Slawek Kaplonski Soniya Vyas Sorin Sbarnea Steve Baker Tobias Urdin Wes Hayutin Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Wallaby. Get Started There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use TripleO and you’ll be running a production cloud in short order. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on Freenode IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net) however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the Freenode IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0

[edge] Open Geospatial Consortium presentation on the next Edge WG call
by Ildiko Vancsa 16 Nov '20

16 Nov '20

Hi, I’m reaching out to draw your attention to an upcoming presentation on the Edge Computing Group weekly call next Monday. We will have a presentation from the Open Geospatial Consortium where you can learn about their use cases relevant to edge computing and more specifically about the importance of location in that context. In the remaining time on the call we will discuss some of the requirements of the use cases such as location-awareness of infrastructure services and look into collaboration opportunities. The call is on __Monday (November 16) at 1400 UTC__. If you are interested in joining the call and the discussions you can find the dial-in information here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Next_meeting:_Monday_.… Please let me know if you have any questions. Thanks, Ildikó

1 1

[neutron] Bug Deputy Report Nov 9-16
by Lucas Alvares Gomes 16 Nov '20

16 Nov '20

Hi, This is the Neutron bug report of the week of 2020-11-09. Critical: * https://bugs.launchpad.net/neutron/+bug/1903982 - "[neutron-tempest-plugin] Error when executing "hostname" in the VM" Assigned to: Rodolfo Alonso * https://bugs.launchpad.net/neutron/+bug/1903531 - "Update of neutron-server breaks compatibility to previous neutron-agent version" Unassigned High: * https://bugs.launchpad.net/neutron/+bug/1904117 - "Nodes in the OVN scenario multinode jobs can't talk to each other" Assigned to: slaweq * https://bugs.launchpad.net/neutron/+bug/1903985 - " [functional] Timeouts during setting link attributes in the namepaces" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903696 - "Security group OVO object don't reloads and make compatible rules objects" Assigned to: slaweq * https://bugs.launchpad.net/neutron/+bug/1903696 - "Security group OVO object don't reloads and make compatible rules objects" Assigned to: slaweq * https://bugs.launchpad.net/neutron/+bug/1903985 - "[functional] Timeouts during setting link attributes in the namepaces" Unassigned Medium: * https://bugs.launchpad.net/neutron/+bug/1903989 - " Bug in logging potentionally causing neutron to fail" Assigned to: Michal Arbet * https://bugs.launchpad.net/neutron/+bug/1903689 - "[stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED'" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903433 - "The duplicate route in l3 router namespace results in North-South traffic breaking" Assigned to: yangjianfeng * https://bugs.launchpad.net/neutron/+bug/1903689 - "stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903982 - " [neutron-tempest-plugin] Error when executing "hostname" in the VM" Assigned to: Rodolfo Alonso * https://bugs.launchpad.net/neutron/+bug/1903989 - " Bug in logging potentionally causing neutron to fail" Assigned to: michalarbet Needs further triage: * https://bugs.launchpad.net/neutron/+bug/1904178 - "[ovn] neutron not support Vlan backed DVR N-Sredirect packet via localnet port," Unassigned * https://bugs.launchpad.net/neutron/+bug/1904041 - " Victoria neutron-db-sync fails with I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903835 - " linuxbridge-agent ERRORS with pyroute2.netlink.exceptions.NetlinkError if ipv6 link local address exist " Unassigned * https://bugs.launchpad.net/neutron/+bug/1903835 - "linuxbridge-agent ERRORS with pyroute2.netlink.exceptions.NetlinkError if ipv6 link local address exist" Unassigned Wishlist: * https://bugs.launchpad.net/neutron/+bug/1904188 - "Include standard attributes ID in OVO dictionaries to improve the OVN revision numbers operation" Assigned to: Rodolfo Alonso

1 0

[kolla] Proposing wu.chunyang for Kolla core
by Mark Goddard 16 Nov '20

16 Nov '20

Hi, I would like to propose adding wu.chunyang to the kolla-core and kolla-ansible-core groups. wu.chunyang did some great work on Octavia integration in the Victoria release, and has provided some helpful reviews. Cores - please reply +1/-1 before the end of Friday 13th November. Thanks, Mark

8 8

CloudKitty deployment on Train and/or Ussuri
by Thode Jocelyn 16 Nov '20

16 Nov '20

Hi, I was looking at the possibilities to have Rating-as-A-Service in our Openstack (currently train but planning to move to Ussuri) and I stumbled upon CloudKitty. I'm currently facing multiple issues with cloudkitty itself and with openstack-ansible. (We are using a containerized deployment with LXC) * I noticed that openstack-ansible has no playbook yet to install a service like CloudKitty even though starting from Ussuri it was added in the ansible-role-requirements.yml. I have created a small patch to be able to install CloudKitty via openstack-ansible and if this is of interest I could potentially submit a PR with this. * The os_cloudkitty role seems to kinda work and only with a relatively old version of CloudKitty. For example, here : https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/st… since CloudKitty v8.0.0 the section should be named "[fetcher_keystone]", but I found no information as to which CloudKitty version should be used with this role. Does someone have any recommendation as to which version should be used and if there is any interest in improving the role to support more recent versions of CloudKitty? * Even when tweaking the configuration and installing v7.0.0 of Cloudkitty it only fixes cloudkitty-processor, I was never able to make cloudkitty-api work I always get an error like "Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings'". Any input on this would be greatly appreciated. Cheers Jocelyn

4 5

[nova] MessageUndeliverable from nova-conductor and MessagingTimeout from nova-compute
by Tony Liu 16 Nov '20

16 Nov '20

It's not about connection, but message transmitting. Title is changed. I am having rabbitmq 3.8.4 and nova 21.0.0. When I check rabbitmq queues for compute, I see 3 messages in compute.compute-1 and 0 messages in other compute node queues. In nova-conductor log of all 3 instances, I see "oslo_messaging.exceptions.MessageUndeliverable". In nova-compute log on compute-1, I see "Timed out waiting for nova-conductor." Actually, 4 out of 5 compute nodes have such warning. One compute node has exception "oslo_messaging.exceptions.MessagingTimeout". "rabbitmqctl list_bindings | grep compute-1" shows this. ================================= exchange compute.compute-1 queue compute.compute-1 [] nova exchange compute.compute-1 queue compute.compute-1 [] ================================= Is this some known issue? How did it happen? What's the cause of it and any way to prevent it from happening? Thanks! Tony > -----Original Message----- > From: Arnaud Morin <arnaud.morin(a)gmail.com> > Sent: Saturday, November 14, 2020 2:10 AM > To: Tony Liu <tonyliu0592(a)hotmail.com> > Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > Subject: Re: [nova-compute] not reconnect to rabbitmq? > > Hello, > > What we noticed in our case is that nova compute is actually > reconnecting, but cannot communicate with the conductor because the > queue binding is either absent or not working anymore. > > So, first, which version of nova are you running? > Which version of rabbitmq? (some bugs related to shadow bindings are > fixed after 3.7.x / dont remember x) > > Can you check if you have any queue related to your compute? > something like that: > rabbtitmqctl list_queues | grep mycompute > > Also check the bindings, better using the management interface or > rabbitmqadmin: > rabbitmqadmin list bindings | grep mycompute > > What usually fixed our issue by the past was to delete / recreate the > binding (easy to do from the management interface). > > Cheers, > > -- > Arnaud Morin > > On 14.11.20 - 00:34, Tony Liu wrote: > > Hi, > > > > I'm having a deployment with Ussuri on CentOS 8. > > I noticed that, in case the connection from nova-compute to rabbitmq > > is broken, nova-compute doesn't reconnect. > > I checked nova-conductor who seems keeping trying reconnect to > > rabbitmq when connection is broken. But nova-compute doesn't seem > > doing the same. I've seen it a few times, after I fixed rabbitmq and > > bring it back, nova-conductor gets reconnected, but nova-compute > > doesn't, I have to manually restart it. Anyone else has the similar > > experiences? > > Anything I am missing? > > > > > > Thanks! > > Tony > > > >

2 2

Where to send mascot graphic adjustment proposals
by Michael Chapman 16 Nov '20

16 Nov '20

While doing some work on the designate docs I wanted to replace the logo on the diagrams (for example https://docs.openstack.org/designate/latest/contributor/architecture.html) with the mascot graphics available, specifically the horizontal one here: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c0… The bottom line of the crocodile is just slightly not aligned with the text, which I think could be improved, and perhaps the crocodile could also be increased in size to match that of the text. In addition, the bottom of the mascots page mentions to contact anne(a)openstack.org which is no longer an active address. Are the above proposed changes reasonable, and is there a new contact available for getting mascot graphics modified? I can change it in the designate diagrams myself but they are marked ND so I don't think that's technically allowed. - Michael

1 0

Which deployment method for ceph (rook|ceph-ansible|tripleo)
by Oliver Weinmann 15 Nov '20

15 Nov '20

Hi, I'm still in the process of preparing a OpenStack POC. I'm 100% sure that I want to use CEPH and so I purchased the book Mastering CEPH 2nd edition. First of all, It's a really good book. It basically explains the various methods how ceph can be deployed and also the components that CEPH is build of. So I played around a lot with ceph-ansible and rook in my virtualbox environment. I also started to play with tripleo ceph deployment, although I haven't had the time yet to sucessfully deploy a openstack cluster with CEPH. Now I'm wondering, which of these 3 methods should I use? rook ceph-ansible tripleo I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of VMs running under vSphere that currently consume storage from a ZFS storage via CIFS and NFS. I don't know if rook can be used for this. I have the feeling that it is purely meant to be used for kubernetes? And If I would like to have CIFS and NFS maybe tripleo is not capable of enabling these features in CEPH? So I would be left with ceph-ansible? Any suggestions are very welcome. Best Regards, Oliver

5 7

[masakari] Teams cleanup
by Radosław Piliszek 14 Nov '20

14 Nov '20

Hello Everyone! To avoid the ghost town effect in Masakari teams, I propose to clean up the memberships. I've already had a chance to discuss it with Takashi Kajinami on IRC [0] as he wanted to remove himself. We have 3 teams (1 gerrit, 2 launchpad): - Gerrit masakari-core [1] - Launchpad masakari-drivers [2] - Launchpad masakari-bugs [3] I plan to set these to the following people: - myself [Radosław Piliszek] (the new PTL) - suzhengwei (new active contributor and core) - Jegor van Opdorp (new active contributor and core) - Sampath Priyankara (the previous PTL) - Tushar Patil (the previously most active core) I will enact the change in a week from now if there are no objections. I also see a few issues likely to discuss with the infra team: 1) Launchpad masakari-drivers - there is a pending invitation for the release team - I doubt it has much use but I would love to see it accepted/rejected/accepted&removed. 2) Gerrit masakari-core - there is an external CI in the core team - why would it need this level of privilege? It does not add its flags to changes, only replies with job status. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-masakari/%23openstack-m… [1] masakari-core: https://review.opendev.org/#/admin/groups/1448,members [2] https://launchpad.net/~masakari-drivers/+members [3] https://launchpad.net/~masakari-bugs/+members Kind regards, -yoctozepto

1 1

[nova-compute] not reconnect to rabbitmq?
by Tony Liu 14 Nov '20

14 Nov '20

Hi, I'm having a deployment with Ussuri on CentOS 8. I noticed that, in case the connection from nova-compute to rabbitmq is broken, nova-compute doesn't reconnect. I checked nova-conductor who seems keeping trying reconnect to rabbitmq when connection is broken. But nova-compute doesn't seem doing the same. I've seen it a few times, after I fixed rabbitmq and bring it back, nova-conductor gets reconnected, but nova-compute doesn't, I have to manually restart it. Anyone else has the similar experiences? Anything I am missing? Thanks! Tony

2 1

[OpenStack][OpenInfra][InteropWG] Interop 2021 Brainstorming
by prakash RAMCHANDRAN 13 Nov '20

13 Nov '20

Hi all, Request you to consider putting down your ideas for Interop 2021 with Open Infrastructure Foundation (OIF) in your mind. https://etherpad.opendev.org/p/interop2021 If you can add inputs by mid-week next, that will be appreciated. Add your inputs and out-of-box thinking. ThanksPrakashFor Interop WG

1 0

Re: [Openstack][InteropWG] Victoria Interop Guidelines Patch and Future Directions
by prakash RAMCHANDRAN 13 Nov '20

13 Nov '20

Hi all, We are in-midst of transition from OSF to OIF and hence decided, not to add more add-ons for Victoria. Note the value and efforts involved in Refstack & Tempest process was in question and answer is we need to identify pointers in Marketplace to confirm the claims for current Marketpalce efforts. Here is the summary of Interop WG call today. 1. Interop Guidelines for 2020.10.json - 2020.10.json (https://opendev.org/osf/interop) - Arkady to try submit to osf/interop - escale to osf staff if needed ( refer https://review.opendev.org/#/c/762705/1/2020.11.json )- Need pointers to results in Markets 2. Interop add-on Guidelines for existing - https://opendev.org/osf/interop/src/branch/master/add-ons2.a DNS (Designate) - dns.2020.10.json - Need pointers to results 2.b Orchestration(Heat) -orchestration.2020.10.json - Need pointers results 3. Interop add-on guidelines for new proposals - https://www.openstack.org/marketplace/3.a FileSystem (Manila) - No plans for Victoria3.b Metal as a Service (Ironic) - No plans for Victoria 4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals - Need Board level guidelines from Foundation Call for volunteers again to ensure we transit from OSF to OIF and please do reply your ideas by email for 1. un-linking orchestration from Heat to Mangnum or Kubernetes as baseline for containers2. Adding new program for BareMetal as a Service with Ironic , bifrost , metal3 etc.3. Putting Integrated OpenStack Integrated logo program on autopilot or terminate the same at Victoria. ThanksPrakashFor Interop WG OSF/OIF On Friday, November 13, 2020, 11:04:48 AM PST, openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> wrote: Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro (Jeremy Stanley) 2. [OpenStack][InteropWG] Weekly Interop meeting Agenda for Victoria Interop Guidelines in next hr (prakash RAMCHANDRAN) 3. Re: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro (Jeremy Stanley) 4. Re: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service (Oliver Walsh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 Nov 2020 17:20:44 +0000 From: Jeremy Stanley <fungi(a)yuggoth.org> To: openstack-discuss(a)lists.openstack.org Subject: Re: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro Message-ID: <20201113172044.c6cgt7rdy6m6mkeu(a)yuggoth.org> Content-Type: text/plain; charset="utf-8" On 2020-11-13 13:58:18 +0100 (+0100), Radosław Piliszek wrote: [...] > I believe it would be a rare situation but surely testing something on > Bionic and trying to release on Focal might have its quirks. Honestly, I think the real problem here is that we have a bunch of unnecessary cruft in the release-openstack-python job held over from when we used to use tox to create release artifacts. If you look through the log of a successful build you'll see that we're not actually running tox or installing the projects being released, but we're using the ensure-tox and bindep roles anyway. We may not even need ensure-pip in there. The important bits of the job are that it checks out the correct state of the repository and then runs `python3 setup.py sdist bdist_wheel` and then pulls the resulting files back to the executor to be published. That should be fairly consistent no matter what project is being built and no matter what distro it's being built on. -- Jeremy Stanley

1 0

[OpenStack][InteropWG] Weekly Interop meeting Agenda for Victoria Interop Guidelines in next hr
by prakash RAMCHANDRAN 13 Nov '20

13 Nov '20

Hi all, Please join me in next hour weekly Interop WG meetingInterop Working Group - Weekly Friday 10-11 AM PST Link: https://meetpad.opendev.org/Interop-WG-weekly-meetin Agenda: 1. Interop Guidelines for 2020.10.json 2. Interop add-on Guidelines for existing2.a DNS (Designate) 2.b Orchestration(Heat)3. Interop add-on guidelines for new proposals3.a FileSystem (Manila)3.b Metal as a Service (Ironic)4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals ThanksPrakashFor Interop WGOpenDev Etherpad | | | | OpenDev Etherpad | | |

1 0

[tripleo] TripleO CI Summary: Unified Sprint 35
by Rafael Folco 13 Nov '20

13 Nov '20

Greetings, The TripleO CI team has just completed **Unified Sprint 35** (Oct 23 thru Nov 12). The following is a summary of completed work during this sprint cycle: In the last sprint we had two major goals: #1 OpenStack Victoria release branching (upstream jobs) and #2 Docker.io removal from upstream CI #1 OpenStack Victoria release branching (upstream jobs) Upstream jobs have been branched for stable/victoria release. Jobs from stable/rocky and stable/stein branches have been deprecated. #2 Docker.io removal from upstream CI Stable branch and CentOS7 jobs have also been converted to content providers. Content provider jobs have been wired-up in more repositories such as puppet-* projects. There are still changes in-flight to be merged, which are expected to happen in the next couple weeks. Content provider changes (160+): https://review.opendev.org/#/q/topic:new-ci-job Upstream promotions [1] Ruck/Rover recorded notes [2]. NEXT SPRINT =========== The planned work for the next sprint is to close-out the content provider work started in the previous sprint, and work on unfinished items for CI related on-going projects: - Elastic recheck / openstack health - Dependency pipeline design and PoC - Job footprint reduction - Cockpit improvements - Quay registry experimentation - Tempest improvements - RPM diff tooling - Reproducer enhancements - Documentation - TripleO core projects - Ansible-role-collect-logs - Upgrade/component pipeline standalone job - Improve container builds The Ruck and Rover shifts for the upcoming weeks are scheduled as follows: Nov 16: Marios Andreou (marios), Ronelle Landy (rlandy) Nov 23: Rafael Folco (rfolco), Arx Cruz (arxcruz) Nov 30: Wesley Hayutin (weshay), Pooja Jadhav (pojadhav) Dec 7: Sorin Sbarnea (zbr), Marios Andreou (marios) Dec 14: Chandan Kumar (chandankumar), Amol Kahat (akahat) Dec 21: Bhagyashri Shewale (bhagyashris), Soniya Vyas (soniya29) Dec 28: Sandeep Yadav (ysandeep), Sagi Shnaidman (sshnaidm) Jan 4: Wesley Hayutin (weshay), Poja Jadhav (pojadhav) Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in hackmd [3]. Thanks, --rfolco [1] http://dashboard-ci.tripleo.org/d/HkOLImOMk/upstream-and-rdo-promotions?org… [2] https://hackmd.io/a_PhAlijTr-KTWHzGuf3qQ [3] https://hackmd.io/R0kCgz_7SHSix_cNgoC9pg

1 0

Re: Ironic use shellinabox doesn't work
by Kaifeng Wang 13 Nov '20

13 Nov '20

There is nothing wrong with the openstack side according to your context, but you need to double check the BMC configuration and kernel parameters before you can make it work in the dashboard or shellinabox web service. You should have something like "console=ttyS0,115200n8" in the kernel parameters, and the parameters should match what's configured in the BIOS. I'd suggest you to start diagnosing with ipmitool because it's the underlying tool used by ironic, try ipmitool <address, port arguments> sol activate, if you can't do anything there, you definity can't do anything from socat/shellinabox. On Fri, Nov 13, 2020 at 4:17 PM Ankele zhang <ankelezhang(a)gmail.com> wrote: > Hello~ Wang > > Thanks for your email very much, you show me hope. > There are some problems that need your help. > > My Ironic baremetal node's BIOS has enabled the SOL, and I have configure > the baremetal node correctly guided by 'https://docs.openstack.org/rocky' > and the result of the command line 'openstack baremetal node console' is > ok, but the SOL page is still frozen. After that, I changed my > enabled_console_interfaces from ipmitool-shellinabox to ipmitool-socat, and > recreate my baremetal node and recreate my nova server, everything is the > same as before, I got a frozen SOL page in dashboard. > > I don't know why the docs of openstack.org is incomplete, or socat or > shellinabox. Maybe you can give me some advice. > Looking forward to your reply again! > > > Ankele > > Kaifeng Wang <kaifeng.w(a)gmail.com> 于2020年11月13日周五上午12:04写道： > >> Hi, >> >> "SOL Session operational" is a BMC prompt, actually you have successfully >> connected to it, before you can interact with the terminal, the Serial >> Redirection (or something called that) needs to be enabled in the BIOS, >> also make sure you have matching baud rate set to the bootloader for the >> tty. >> >> P.S. SOL does not work for Windows systems. >> >> On Thu, Nov 12, 2020 at 11:05 PM Ankele zhang <ankelezhang(a)gmail.com> >> wrote: >> >>> Hello~ >>> >>> I have a OpenStack platform( Rocky ) on CentOS7.6, and I installed >>> Ironic components on it. I can manage bare metal node with Ironic and I >>> plan to use shellinabox to manage the bare metal node remotely. >>> I had config conductor ironic.conf: >>> [DEFAULT] >>> ... >>> enabled_console_interfaces = ipmitool-shellinabox,no-console >>> I had config shellinabox: >>> USER=shellinabox >>> GROUP=shellinabox >>> CERTDIR=/var/lib/shellinabox >>> PORT=4200 >>> OPTS="--disable-ssl-menu -s /:LOGIN" >>> My 'openstack baremetal node console show BM01': >>> console_enabled: True and console_info.url: http://192.168.3.84:8023 >>> [image: image.png] >>> Now, I can access https://192.168.3.84:4200 is OK, and I can log >>> in and manage it. >>> But, when I access http://192.168.3.84:8023: >>> [image: image.png] >>> can not type anything into it. >>> >>> Look forward to hearing from you! >>> >>> >>> Ankele >>> >>> >>>

1 0

[cinder][ops] restricting the Ceph version used with Cinder
by Brian Rosmaita 13 Nov '20

13 Nov '20

The Cinder project plans to take advantage of recent developments in Ceph to make some improvements to the RBD driver. To do that, we propose restricting the Cinder-supported releases of Ceph to the active stable releases plus the two prior releases. This will make Mimic the minimum supported version of Ceph for the Wallaby and X releases of Cinder. This is explained in a bit more detail in a patch to the RBD driver documentation: https://review.opendev.org/#/c/762592/ If you have concerns about this proposal, please leave comments on the review. Thank you, brian

3 2

[neutron] BaGPipe experiences
by Michael Richardson 13 Nov '20

13 Nov '20

Hi all, Is anyone using the BaGPipe driver[0] in production? Any comments, experiences, config. recommendations, war stories, tales of caution you would like to share? Cheers, Michael [0] https://docs.openstack.org/networking-bagpipe/latest/ -- Michael Richardson Catalyst Cloud || Catalyst IT Limited https://catalystcloud.nz/ GPG: 0530 4686 F996 4E2C 5DC7 6327 5C98 5EED A30

3 2

Re: Cannot deploly an instance at a specific host --(no such host found) [nova]
by Pavlos Basaras 13 Nov '20

13 Nov '20

Hello, thanks very much for your prompt reply. regarding the first command "nova-manage cell_v2 list_hosts" the output is the following (openstack is the host of the controller). I dont see any other node here, even when i execute the discover_hosts command +-----------+--------------------------------------+-----------+ | Cell Name | Cell UUID | Hostname | +-----------+--------------------------------------+-----------+ | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | +-----------+--------------------------------------+-----------+ Also this is the output from my controller when i use the command: sudo -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not sure if this helps) Found 2 cell mappings. Skipping cell0 since it does not contain hosts. Getting computes from cell 'cell1': 1522c22f-64d4-4882-8ae8-ed0f9407407c Found 0 unmapped computes in cell: 1522c22f-64d4-4882-8ae8-ed0f9407407c any thoughts? best, Pavlos.

2 7

[neutron] Drivers meeting agenda
by Slawek Kaplonski 12 Nov '20

12 Nov '20

Hi, For tomorrow's drivers meeting we have one item in the "On Demand" section. It's added by Oleg and is related to the bug https://bugs.launchpad.net/ neutron/+bug/1887523/ So lets meet tomorrow and discuss about that. See You on the meeting :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[swift]: issues with multi region (swift as backend for glance)
by fsbiz＠yahoo.com 12 Nov '20

12 Nov '20

Hi folks, We're on queens release. We have just setup a 2nd region. So, now we have two regions regionOne and regionTwo We had a storage cluster in regionOne. Everything works good.We also added another storage cluster in regionTwo and have created swift endpoints for this.Using swift API, everything works fine. The container is properly created in regionOne or regionTwo asdesired. We are also using swift as the glance backend. We are seeing an issue with this for regionTwo.When I create an image in regionTwo, it seems like the glance storage backend is not properly recognizingthe endpoint and wants to store the image in regionOne. This looks like a definite bug.I can work around it by overriding the endpoint using swift_store_endpoint but if there is a known bugabout this issue I would rather patch it than resort to overriding the URL endpoint returned from "auth". Is this a known bug ? Again, we are on the latest Queens release. thanks,Fred.

2 2

[manila] IRC meetings canceled on Nov 19th and Nov 26th
by Goutham Pacha Ravi 12 Nov '20

12 Nov '20

Hello Zorillas, As Vida Haririan informed us [1], we'll be hosting a bug triage call on Meetpad [2] instead of our weekly IRC meeting on 19th November 2020. We hope that you will all join us and squash one or more bugs on 19th! 26th November 2020 is a holiday in the US; and a bulk of the regular attendees will be off their computers. We discussed this in the meeting today, and decided to cancel this IRC meeting. Please share any concerns to #openstack-manila or here on this mailing list. Thanks, Goutham Pacha Ravi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018629… [2] https://meetpad.opendev.org/ManilaW-ReleaseBugSquash

1 0

Queens steal time [nova]
by Budai Laszlo 12 Nov '20

12 Nov '20

Hello all, we are comparing the behavior of our queens openstack with kilo. In queens we are observing an increase in the steal time reported in the guest along with the increase of the load averages. All this is happening while the host is not overloaded, and reports 80+ idle time Initially we have suspected that the overcommit might be the reason of the steal, so we have migrated vms, and now there are 42 vCPUs used out of the 48 pCPUs, but in the guest we still observe the steal time. with similar configuration in openstack kilo we see smaller load, and almost no steal time at all. what could be the reason of this steal time when there is no CPU overcommit? Thank you for any ideas. Kind regards, Laszlo

2 3

Victoria Release Community Meeting
by helena＠openstack.org 12 Nov '20

12 Nov '20

Hello, The community meeting for the Victoria release will be this Thursday, November 12th at 16:00 UTC. The meeting will be held via Zoom. We will show pre-recorded videos from our PTLs followed by live Q&A sessions. We will have updates from Masakari, Telemetry, Neutron, and Cinder. Zoom Info: [ https://zoom.us/j/2146866821?pwd=aDlpOXd5MXB3cExZWHlROEJURzh0QT09 ]( https://zoom.us/j/2146866821?pwd=aDlpOXd5MXB3cExZWHlROEJURzh0QT09 ) Meeting ID: 214 686 6821 Passcode: Victoria Find your local number: [ https://zoom.us/u/8BRrV ]( https://zoom.us/u/8BRrV ) Reminder to PTLs: We would love for you to participate and give an update on your project. I have attached a template for the slides that you may use if you wish. The video should be around 10 minutes. Please send in your video and slide for the community meeting ASAP. I have only received content for the listed above projects. If you are unable to make the meeting at the designated time we can show your video and forward any questions for you. Let me know if you have any other questions! Thank you for your participation, Helena

7 11

Ironic use shellinabox doesn't work
by Ankele zhang 12 Nov '20

12 Nov '20

Hello~ I have a OpenStack platform( Rocky ) on CentOS7.6, and I installed Ironic components on it. I can manage bare metal node with Ironic and I plan to use shellinabox to manage the bare metal node remotely. I had config conductor ironic.conf: [DEFAULT] ... enabled_console_interfaces = ipmitool-shellinabox,no-console I had config shellinabox: USER=shellinabox GROUP=shellinabox CERTDIR=/var/lib/shellinabox PORT=4200 OPTS="--disable-ssl-menu -s /:LOGIN" My 'openstack baremetal node console show BM01': console_enabled: True and console_info.url: http://192.168.3.84:8023 [image: image.png] Now, I can access https://192.168.3.84:4200 is OK, and I can log in and manage it. But, when I access http://192.168.3.84:8023: [image: image.png] can not type anything into it. Look forward to hearing from you! Ankele

2 1

[Manila] Manila user overwriting existing Ceph users
by Babel Jahson 12 Nov '20

12 Nov '20

Hello everyone, I'm currently testing manila with CephFS and I stumbled upon a behavior where manila is able to overwrite existing Ceph users. In my testing setup glance, nova, cinder and manila share the same Ceph cluster. However they have different users. In this situation when you create a share and allow acces via "manila access-allow cephshare1 cephx test" If the user "test" is already used to access some pools on the cluster, let's say cinder-volume or glance-images it will be overwritten with the permissions for the share. Which will break any resources that was using it. I've recheck the configuration files multiple times to see if I could set some properties to avoid this but I didn't find any. By quickly looking at the code here : https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers… A check is done but only for the manila user. I'm on Rocky version but this part doesn't seems to have changed since. That lead me to some questions : - Does manila must have his own dedicated Ceph cluster ? - Is there any workaroud to this ? Other than putting some gibberish names for services users ? - Is it possible to lock some users in the Ceph cluster to prevent this behavior ? If someone has some clues on this, thanks in advance. Jahson.B

3 4

multiple nfs shares with cinder-backup
by MaSch 12 Nov '20

12 Nov '20

Hello all! I'm currently using openstack queens with cinder 12.0.10. I would like to a backend I'm using a NFS-share. Now i would like to spit my backups up to two nfs-shares. I have seen that the cinder.volume.driver can handle multiple nfs shares. But it seems that cinder.backup.driver can not. Is there a way to use two nfs shares for backups? Or is it maybe possible with a later release of Cinder? regards, MaSch

3 4

[tripleo] stein branch transition to extended maintenance
by Marios Andreou 12 Nov '20

12 Nov '20

Hello TripleOs The stein branch is about to transition to extended maintenance [1]. This will happen after the proposal at [2] is approved (by us) and merged. The latest release of stein for each of the repos in [2] will be tagged as extended maintenance. We have the option of first making another (final) release, if there is something newer in stein that we need to be included. We will continue to allow for bug fixes to be committed to stein however there will be no more releases made after this point. So, does anyone need a final release made for the stein branch for one of the repos in [3]. If no one speaks up then I will +1 the patch at [2] tomorrow thanks, marios [1] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [2] https://review.opendev.org/#/c/762411/ [3] https://releases.openstack.org/teams/tripleo.html#stein

1 0

[cyborg] Propose Wenping Song for Cyborg core
by yumeng bao 12 Nov '20

12 Nov '20

Hi team, I would like to propose adding Wenping Song<songwenping(a)inspur.com> to the cyborg-core groups. Wenping did some great work on arq microversion and FPGA new driver support in the Victoria release, and has provided some helpful reviews. Cores - please reply +1/-1 before the end of Wednesday 18th November. Regards， Yumeng

4 3

[all] Fixtures & monkey patching issue with Python 3.9
by Thomas Goirand 11 Nov '20

11 Nov '20

Hi, Please see these: https://bugs.debian.org/973239 https://github.com/testing-cabal/fixtures/issues/44 Is this affecting OpenStack? Could I just ignore these tests? Or is there an easy solution? Cheers, Thomas Goirand (zigo)

2 1

Question about the instance snapshot
by Henry lol 11 Nov '20

11 Nov '20

Hello, everyone I'm wondering whether the snapshot from the instance saves all disks attached to the instance or only the main(=first) disk, because I can't find any clear description for it. If the latter is true, should I detach all disks except for the main from the instance before taking a snapshot, and why doesn't it support all attached disks? Thanks Sincerely,

3 2

Re: CentOS 8 Ussuri can't launch instance /usr/libexec/qemu-kvm: Permission denied
by Oliver Weinmann 11 Nov '20

11 Nov '20

Hi again, sorry to pick up this old post again but I manged to figure out what's wrong. The error: end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) only arises when using the nano flavor: openstack flavor create --id 0 --vcpus 1 --ram 64 --disk 1 m1.nano It works fine when using 128 instead of 64MB RAM: openstack flavor create --id 0 --vcpus 1 --ram 128 --disk 1 m1.nano Cheers, Oliver Am 19. Oktober 2020 um 16:21 schrieb Oliver Weinmann <oliver.weinmann(a)me.com>: Ok, I will try to disable selinux and deploy one more compute node. I just stumbled across another issue, not sure if it is related. The instance seems to be deployed just fine but now I looked on the console and neither cirros nor centos 7 seem to be booting up correctly. on cirros i see an error: [ 0.846019] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- and on centos7: error: not a correct XFS inode. I tried to create with ephemeral and volume. Cheers, Oliver Am 19. Oktober 2020 um 16:09 schrieb Alex Schultz <aschultz(a)redhat.com>: On Mon, Oct 19, 2020 at 7:59 AM Oliver Weinmann <oliver.weinmann(a)me.com> wrote: First of all thanks a lot for the quick reply. I just checked and it seems that the package is really not available for centos8 from the upstream repo: https://centos.pkgs.org/8/centos-appstream-x86_64/podman-1.6.4-15.module_el… When you say it should be available via rdo, does this mean I have to add or use a different repo when deploying undercloud / overcloud? I have followed the tripleo guide to deploy it: I thought we shipped it, maybe we don't because we run with selinux disabled so it doesn't show up in CI. https://docs.openstack.org/tripleo-docs/latest/ And is there a way to disable selinux on all overcloud nodes by default? I guess it is the default to disable it? Set the following in an environment file as part of the deployment: parameter_defaults: SELinuxMode: permissive Cheers, Oliver Am 19. Oktober 2020 um 15:29 schrieb Alex Schultz <aschultz(a)redhat.com>: On Mon, Oct 19, 2020 at 7:09 AM Oliver Weinmann <oliver.weinmann(a)me.com> wrote: Hi all, I have successfully deployed the overcloud many many times, but this time I have a strange behaviour. Whenever I try to launch an instance it fails. I checked the logs on the compute node and saw this error: Failed to build and run instance: libvirt.libvirtError: internal error: process exited while connecting to monitor: libvirt: error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied googling led me to the solution to disable selinux: setenforce 0 I have not made this change persistent yet, as I would like to know why I'm facing this issue right now. What is actually the default for the overcloud nodes SeLinux? Enforcing, permissive or disabled? I build the ipa and overcloud image myself as I had to include drivers. Is this maybe the reason why SeLinux is now enabled, but is actually disabled when using the default ipa images? From a TripleO perspective, we do not officially support selinux enabled when running with CentOS. In theory it should work, however it is very dependent on versions. I think you're likely running into an issue with the correct version of podman which is likely causing this. We've had some issues as of late which require a very specific version of podman in order to work correctly with nova compute when running with selinux enabled. You need 1.6.4-15 or higher which I don't think is available with centos8. It should be available via RDO. Related: https://review.opendev.org/#/c/736173/ Thanks and Best Regards, Oliver

1 0

[octavia] Timeouts during building of lb? But then successful
by Florian Rommel 11 Nov '20

11 Nov '20

Hi, so we have a fully functioning setup of octavia on ussuri and it works nicely, when it competes. So here is what happens: From octavia api to octavia worker takes 20 seconds for the job to be initiated. The loadbalancer gets built quickly and then we get a mysql went away error, the listener gets built and then a member , that works too, then the mysql error comes up with query took too long to execute. Now this is where it gets weird. This is all within the first 2 - 3 minutes. At this point it hangs and takes 10 minutes (600 seconds) for the next step to complete and then another 10 minutes and another 10 until it’s completed. It seems there is a timeout somewhere but even with debug on we do not see what is going on. Does anyone have a mysql 8 running and octavia executing fine? And could send me their redacted octavia or mysql conf files? We didn’t touch them but it seems that there is something off.. especially since it then completes and works extremely nicely. I would highly appreciate it , even off list. Best regards, //f

3 4

Re: [ironic] Configuration mold follow-up
by Jaunteva, Aija 11 Nov '20

11 Nov '20

Hi, thank you for the responses to the poll. The meeting to discuss outstanding questions will be held on Thu, Nov 19, 2020 15:00 UTC. For details see [1]. Regards, Aija [1] https://etherpad.opendev.org/p/ironic-configuration-molds

1 0

Cannot deploly an instance at a specific host --(no such host found) [nova]
by Pavlos Basaras 11 Nov '20

11 Nov '20

Dear community, i am new to openstack. I have deployed devstack (on a virtual machine), and I can successfully deploy instances at the host where the controller is installed. I followed the instructions from https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html to add a new compute host, in order to be able to deploy VMs at the PC. Here is the output: openstack compute service list --service nova-compute +----+--------------+-----------+------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+--------------+-----------+------+---------+-------+----------------------------+ | 3 | nova-compute | openstack | nova | enabled | up | 2020-11-11T07:10:41.000000 | | 5 | nova-compute | computenode | nova | enabled | up | 2020-11-11T07:10:42.000000 | +----+--------------+-----------+------+---------+-------+----------------------------+ "computenode" is the new device that i added. When i try to deploy an instance from cli: openstack server create --flavor m1.tiny --image cirros034 --nic net-id=internal --security-group c8b06902-6664-4776-a8e9-0735ae251d34 --availability-zone nova:computenode mym--debug the reply i see from horizon is since there is an error in deploying the instance No valid host was found. No such host - host: computenode node: None any directions? all the best, Pavlos

2 1

[cinder][ceilometer][heat][instances] Installation Problems
by fisheater chang 11 Nov '20

11 Nov '20

To whom it may concern, I am new to openstack, I got several errors when I installed the service followed by the installation guide. My openstack version : stein Ubuntu 18.0.4 1. Cinder-api is in /usr/bin/cinder-api, but when I type service cinder-api status, it shows Unit cinder-api.service could not be found. 2. Ceilometer and Heat tab didn't show in the Dashboard. 3. I was trying to launch an instance, but I got the status error and I tried to delete, but the instances can not be deleted. And I used nova force-delete instance-id, the error message is ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. <class 'nova.exception.AllocationDeleteFailed'> (HTTP 500) (Request-ID: req-e6c0d966-c7ec-4f20-8e9f-c788018a8d81) I explored the openstack installation myself, just wondering if there is any online hands-on training or course that I can enroll in? Thanks. Kind regards, Walsh

1 0

[tc][all][karbor] Retiring the Karbor project
by Kendall Nelson 10 Nov '20

10 Nov '20

Hello Everyone, As you know, Karbor is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Karbor repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Karbor, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Karbor will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Karbor contributors and PTLs (especially Pengju Jiao) for maintaining this project. -Kendall Nelson (diablo_rojo) [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=karbor-group&metric=c… <https://www.stackalytics.com/?release=victoria&module=qinling-group&metric=…> [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-reposito… [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re…

2 1

[tc][all][karbor] Retiring the Qinling project
by Kendall Nelson 10 Nov '20

10 Nov '20

Hello Everyone, As you know, Karbor is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Karbor repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Karbor, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Karbor will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Karbor contributors and PTLs (especially Pengju Jiao) for maintaining this project. -Kendall Nelson (diablo_rojo) [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=karbor-group&metric=c… <https://www.stackalytics.com/?release=victoria&module=qinling-group&metric=…> [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-reposito… [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re…

1 1

[openstack][qa][tempest] tempest cleanup ansible role
by Martin Kopec 10 Nov '20

10 Nov '20

Hello all, we have implemented a tempest-cleanup ansible role [1] which runs the 'tempest cleanup' tool [2]. The role might be beneficial for you in case you run tempest tests multiple times within the same environment and you wanna make sure no leftover resources are present after the first run. The other great use case is to verify that your tempest tests are not leaving any resources behind after the tests are completed. 'tempest cleanup' can take care of the services defined here [3] - a service which doesn't have a class definition there cannot be discovered by the tool. If the resource you would wanna have cleaned is not in [3] help us please improve the tool and tell us about it or add it there yourself. [1] https://opendev.org/openstack/tempest/src/branch/master/roles/tempest-clean… [2] https://docs.openstack.org/tempest/latest/cleanup.html [3] https://opendev.org/openstack/tempest/src/branch/master/tempest/cmd/cleanup… Regards, -- Martin Kopec Quality Engineer Red Hat EMEA <https://www.redhat.com> <https://red.ht/sig>

1 0

[ironic] SPUC times!
by Dmitry Tantsur 10 Nov '20

10 Nov '20

Hi folks, I nearly forgot about SPUC, can you imagine? :) Anyway, after staring at the doodle for some time (it wasn't easy!), I've picked two time slots: Friday, 10am UTC (in https://bluejeans.com/643711802) Friday, 5pm UTC (in https://bluejeans.com/313987753) Apologies for those who cannot make them! We're starting this Friday (the 13th!). I'm taking a day off, so I won't necessarily be present, but feel free to use the meeting IDs without me as well. SPUC will run till X-mas (maybe we should even have an X-mas special on the 25th?). Cheers, Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

2 1

[neutron] Bug deputy week 45 (2020/10/02 - 2020/10/08)
by Rodolfo Alonso Hernandez 10 Nov '20

10 Nov '20

Hello: This is the weekly summary of Neutron bugs reported: Critical: - https://bugs.launchpad.net/neutron/+bug/1902678 [Fullstack] Wrong output of the cmdline causes tests timeouts Patch: https://review.opendev.org/#/c/761202/ - https://bugs.launchpad.net/neutron/+bug/1902843 [rocky]Rally job is broken in the Neutron stable/rocky branch *Not assigned* - https://bugs.launchpad.net/neutron/+bug/1902844 Error while removing subnet after test *Not assigned* High: - https://bugs.launchpad.net/neutron/+bug/1902775 neutron-rally-task fails on stable/rocky: SyntaxError: invalid syntax Patch: https://review.opendev.org/#/c/761391/ (merged) - https://bugs.launchpad.net/neutron/+bug/1902917 Anti-spoofing bypass using Open vSwitch *Not assigned* - https://bugs.launchpad.net/neutron/+bug/1903696 Security group OVO object don't reloads and make compatible rules objects Medium: - https://bugs.launchpad.net/neutron/+bug/1902888 [OVN] neutron db sync does not sync external_ids for routes Patch: https://review.opendev.org/#/c/761420/ - https://bugs.launchpad.net/neutron/+bug/1902950 [OVN] DNS resolution not forwarded with OVN driver *Not assigned* - https://bugs.launchpad.net/neutron/+bug/1902998 tempest test_create_router_set_gateway_with_fixed_ip often fails with DVR Patch: https://review.opendev.org/#/c/761498/ - https://bugs.launchpad.net/neutron/+bug/1903433 The duplicate route in l3 router namespace results in North-South traffic breaking Patch: https://review.opendev.org/#/c/761829/ - https://bugs.launchpad.net/neutron/+bug/1903689 [stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED' *Not assigned* Low: - https://bugs.launchpad.net/neutron/+bug/1903008 Create network failed during functional test *Not assigned* Regards.

1 0

[Manila] Bug Squash upcoming event on 19th Nov 2020
by Vida Haririan 10 Nov '20

10 Nov '20

Hi everyone, Back by popular demand :) We are planning the next Bug Squash session focusing on bugs that require API/DB changes as identified in Victoria Cycle. The event will be held all day on 19th Nov 2020, with a synchronous bug triage call at 15:00 UTC using this Jitsi bridge [1]. A list of bugs targeted for the Wallaby Cycle are available for review [2]. Please Feel free to flag an existing bug on the list or add any bugs that you plan on addressing early in the Cycle. Your participation is much appreciated, and we look forward to you joining us for this event. Thanks in advance, Vida [1] https://meetpad.opendev.org/ManilaW-ReleaseBugSquash [2] https://ethercalc.openstack.org/birpr9a6bd0b

1 0

[oslo] New courtesy ping list for Wallaby
by Herve Beraud 10 Nov '20

10 Nov '20

Hello, As we discussed during our previous meeting, I'll be clearing the current ping list in the next few weeks. This is to prevent courtesy pinging people who are no longer active on the project. If you wish to continue receiving courtesy pings at the start of the Oslo meeting please add yourself to the new list on the agenda template [1]. Note that the new list is above the template, called "Courtesy ping for Wallaby". If you add yourself again to the end of the existing list I'll assume you want to be left on though. Thanks. Hervé [1] https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template -- 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

Unable to build centos 8.2 qcow2
by Akshay 346 09 Nov '20

09 Nov '20

Hello All, I need to build centos 8.2 image using disk-image-builder. But by setting DIB_RELEASE with 8, it by default uses centos8.1 as base cloud image. How can I use centos 8.2 image? Also I tried setting DIB_CLOUD_IMAGES having my local path to centos 8.2 qcow2 but it appends centos8.1 name at the defined path. i.e /path/to/my/dir/centos8.2/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 Please suggest how may I build centos 8.2 qcow2. Be safe Akshay DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

2 1

[baremetal-sig][ironic] Tue Nov 10, 2pm UTC: Baremetal and ML2 networking
by Arne Wiebalck 09 Nov '20

09 Nov '20

Dear all, The Bare Metal SIG will meet tomorrow, Tue Nov 10 at 2pm UTC, with a "topic-of-the-day"(*) presentation by Julia on Bare Metal + ML2 Networking: Why it is this way (feat. 3d printer calibration cubes!) All details for this meeting and upcoming topics can be found on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne (*) The Bare Metal SIG has at each meeting a ~10 minute introduction to or presentation of a bare metal related topic.

1 0

openvswitch+dpdk 100% cpu usage of ovs-vswitchd
by Satish Patel 09 Nov '20

09 Nov '20

Folks, Recently i have added come compute nodes in cloud supporting openvswitch-dpdk for performance. I am seeing all my PMD cpu cores are 100% cpu usage on linux top command. It is normal behavior from first looks. It's very scary to see 400% cpu usage on top. Can someone confirm before I assume it's normal and what we can do to reduce it if it's too high?

4 11

[neutron] Use the same network interface with multiple ML2 mechanism drivers
by Gabriel Omar Gamero Montenegro 09 Nov '20

09 Nov '20

Dear all, I know that ML2 Neutron core plugin is designed to support multiple mechanism and type drivers simultaneously. But I'd like to know: is it possible to use the same network interface configured with different ML2 mechanism drivers? I'm planning to use openvswitch and linuxbridge as mechanism drivers along with VLAN as type driver. Could it be possible to have the following configuration for that purpose?: ml2_conf.ini: [ml2] mechanism_drivers = openvswitch,linuxbridge [ml2_type_vlan] network_vlan_ranges = physnet1:40:60,physnet2:60:80 eth3 is a port of the provider bridge: ovs-vsctl add-port br-provider eth3 openvswitch_agent.ini: [ovs] bridge_mappings = physnet1:br-provider linuxbridge_agent.ini: [linux_bridge] physical_interface_mappings = physnet2:eth3 If it's mandatory to use different network interfaces any guide or sample reference about implementing multiple mechanism drivers would be highly appreciated. Thanks in advance, Gabriel Gamero

3 3

Re: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed
by Thierry Carrez 09 Nov '20

09 Nov '20

zuul(a)openstack.org wrote: > - release-openstack-python https://zuul.opendev.org/t/openstack/build/652843f2641e47d781264a815a14894d : POST_FAILURE in 2m 54s During the release job for ansible-role-redhat-subscription 1.1.1, twine upload to PyPI failed with: HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/ The description failed to render in the default format of reStructuredText. See https://pypi.org/help/#description-content-type for more information. It's weird because it looks like this was addressed about a year ago, and nothing significant changed in that area in the months following 1.1.0 release. Current status: Tag was pushed OK No tarball upload No PyPI upload Once the issue is fixed, the tag reference should be reenqueued. -- Thierry Carrez (ttx)

4 10

[magnum] heat-container-agent:victoria-dev
by Ionut Biru 09 Nov '20

09 Nov '20

Hi, 20 days ago the image was updated and now all clusters fail to deploy because it cannot find /usr/bin/kubectl, i think. /usr/bin/kubectl apply -f /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system Some services are installed using full path instead of simply kubectl. Should the image be fixed or reverted the changes to old revision or we should just fix the scripts? -- Ionut Biru - https://fleio.com

2 11

[kolla] IRC meeting cancelled on 11th November
by Mark Goddard 09 Nov '20

09 Nov '20

Hi, Since I and a number of cores are away on Wednesday 11th November, let's cancel the IRC meeting. The focus should be on continuing to stabilise the Victoria release. Thanks, Mark

1 0

[largescale-sig] Future meeting time
by Thierry Carrez 09 Nov '20

09 Nov '20

Hi everyone, During the PTG we discussed our meeting time. Currently we are rotating every two weeks between a APAC-EU friendly time (8utc) and a EU-US friendly time (16utc). However, rotating the meeting between two timezones resulted in fragmenting the already-small group, with only Europeans being regular attendees. After discussing this at the PTG with Gene Kuo, we think it's easier to have a single meeting time, if we can find one that works for all active members. Please enter your preferences into this date poll for Wednesday times: https://framadate.org/ue2eOBTT3QXoFhKg Feel free to add comments pointing to better times for you, like other days that would work better for you than Wednesdays for example. -- Thierry Carrez (ttx)

1 1

[neutron]Drivers meeting 06.11.2020 - cancelled
by Slawek Kaplonski 06 Nov '20

06 Nov '20

Hi, We don't have any new RFEs to discuss so lets cancel tomorrow's drivers meeting. There is one fresh RFE [1] but we discussed that durig the PTG so now lets wait for proposed spec with more details and we will get back to discussion about approval of it in the drivers meeting in next weeks. Have a great weekend. [1] https://bugs.launchpad.net/neutron/+bug/1900934 -- Slawek Kaplonski Principal Software Engineer Red Hat

3 4

[openstack-ansible][nova] os-nova-install.yml playbook fails after being unable to restart libvirtd.service on compute nodes
by Oliver Wenz 06 Nov '20

06 Nov '20

To enable live migration on an ussuri (deployed using OpenStack Ansible) I set up a shared filesystem (ocfs2) on the compute hosts. Then I added the following to /etc/openstack_deploy/user_variables.yml and reran the os-nova-install.yml playbook: ``` nova_nova_conf_overrides: libvirt: iscsi_use_multipath: true nova_system_user_uid: 999 nova_system_group_gid: 999 nova_novncproxy_vncserver_listen: 0.0.0.0 # Disable libvirtd's TLS listener nova_libvirtd_listen_tls: 0 # Enable libvirtd's plaintext TCP listener nova_libvirtd_listen_tcp: 1 nova_libvirtd_auth_tcp: none ``` The playbook failed with the following message: ``` RUNNING HANDLER [os_nova : Restart libvirt-bin] *************************************************************************** fatal: [compute1]: FAILED! => {"changed": false, "msg": "Unable to restart service libvirtd: Job for libvirtd.service failed because the control process exited with error code.\nSee \"systemctl status libvirtd.service\" and \"journalctl -xe\" for details.\n"} ``` (similar for the other compute nodes) Running 'systemctl status libvirtd.service' revealed that the service failed to start (code=exited, status=6). Here's the 'journalctl -xe' output: ``` Nov 06 12:42:20 bc1bl12 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Service hold-off time over, scheduling restart. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Scheduled restart job, restart counter is at 5. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Automatic restarting of the unit libvirtd.service has been scheduled, as the result for -- the configured Restart= setting for the unit. Nov 06 12:42:20 bc1bl12 systemd[1]: Stopped Virtualization daemon. -- Subject: Unit libvirtd.service has finished shutting down -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit libvirtd.service has finished shutting down. Nov 06 12:42:20 bc1bl12 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 06 12:42:20 bc1bl12 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Start request repeated too quickly. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Failed with result 'exit-code'. Nov 06 12:42:20 bc1bl12 systemd[1]: Failed to start Virtualization daemon. -- Subject: Unit libvirtd.service has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit libvirtd.service has failed. -- -- The result is RESULT. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd-admin.socket: Failed with result 'service-start-limit-hit'. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.socket: Failed with result 'service-start-limit-hit'. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd-ro.socket: Failed with result 'service-start-limit-hit'. Nov 06 12:42:20 bc1bl12 systemd[1]: Closed Libvirt local read-only socket. -- Subject: Unit libvirtd-ro.socket has finished shutting down -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit libvirtd-ro.socket has finished shutting down. ``` The /etc/libvirt/libvirtd.conf file written by OpenStack Ansible looks like this: ``` listen_tls = 0 listen_tcp = 1 unix_sock_group = "libvirt" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0770" auth_unix_ro = "none" auth_unix_rw = "none" auth_tcp = "none" ``` I've encountered mentions of /etc/default/libvirt-bin in documentation for older OpenStack versions and I'm unsure if something went wrong with the playbooks, because the file doesn't exist on my compute nodes. Any ideas that might help are highly appreciated! Kind regards, Oliver

1 0

[neutron][stable]Proposing Rodolfo Alonso Hernandez as a stable branches core reviewer
by Slawek Kaplonski 06 Nov '20

06 Nov '20

Hi, I would like to propose Rodolfo Alonso Hernandez (ralonsoh) to be new member of the Neutron stable core team. Rodolfo works in Neutron since very long time. He is core reviewer in master branch already. During last few cycles he also proved his ability to help with stable branches. He is proposing many backports from master to our stable branches as well as doing reviews of other backports. He has knowledge about stable branches policies. I think that he will be great addition to our (not too big) stable core team. I will open this nomination open for a week to get feedback about it. -- Slawek Kaplonski Principal Software Engineer Red Hat

6 6

[openstack][ptg][InteropWG] : Conclusion of InteropWG session 10/26 - next one will be 10/30
by prakash RAMCHANDRAN 06 Nov '20

06 Nov '20

Hi all My apology on the delayed start and here is the items we went over on first session. Refer : https://etherpad.opendev.org/p/interop-wallaby-ptg (Monday 10/26 recorded the meeting for everyone to see, its cloud recording and will know from PTG hosts where they have that?) Summary:1. Plan to Complete Victoria guidelines specs for interop in 2-6 weeks depending on adding new [OpenStack Powered File System Branding as Add-on Program] - last Ussuri guidelines are at https://opendev.org/osf/interop/src/branch/master/2020.06.json New one will be 2020.10.json to be added - For existing integrated modules [ Core OpenStack services including identity, compute, networking, block storage, and object storage ] - for two existing add-ons [Orchestration (heat) , DNS (designate) "Not a core capability, add-on program is available" - This is for Manila Filesystem add-on https://etherpad.opendev.org/p/wallaby-ptg-manila-interop "Not a core capability, add-on program to be made available" We have one more opportunity on 10/30 slot at the end of PTG if BMaaS (Ironic) if Julia has any proposals, besides (Open Infra Kata + Docker) Container has additional proposal community is working on. Look forward to seeing you all on October 30 as what the Road-map will look like for 2020 and 2021 going forward. ThanksPrakash On Monday, October 26, 2020, 06:09:00 AM PDT, Goutham Pacha Ravi <gouthampravi(a)gmail.com> wrote: Hi Prakash, We're here: https://zoom.us/j/92649902134?pwd=a01aMXl6ZlNEZDlsMjJMTGNMVUp1UT09 On Mon, Oct 26, 2020 at 6:06 AM prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: https://meetpad.opendev.org/Interop-WG-weekly-meeting

3 5

freezer
by Ali Ebrahimpour 06 Nov '20

06 Nov '20

hi i recently install the freezer api and i have problem with using it if run this command: freezer-agent --debug --action backup --nova-inst-id a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container /tmp/ali --backup-name test --mode nova --engine nova --no-incremental true --log-file a.log --consistency-check and freezer api doesn't work current and error with: Engine error: a bytes-like object is required, not 'str' Engine error: Forced stop Adn attach the log please help me ! thank you for attention

3 3

[nova] Wallaby spec review day
by Balázs Gibizer 06 Nov '20

06 Nov '20

Hi, Wallaby Milestone 1 is four weeks from now. As Sylvain raised on the weekly meeting it is a good time to have a spec review day somewhere before M1. So I'm proposing 17th of November as spec review day. Let me know if it what you think. Cheers, gibi

1 0

[cinder][ceilometer][heat][instances] Installation Problems
by WALSH CHANG 06 Nov '20

06 Nov '20

To whom it may concern, I am new to openstack, I got several errors when I installed the service followed by the installation guide. My openstack version : stein Ubuntu 18.0.4 1. Cinder-api is in /usr/bin/cinder-api, but when I type service cinder-api status, it shows Unit cinder-api.service could not be found. 2. Ceilometer and Heat tab didn't show in the Dashboard. 3. I was trying to launch an instance, but I got the status error and I tried to delete, but the instances can not be deleted. And I used nova force-delete instance-id, the error message is ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. <class 'nova.exception.AllocationDeleteFailed'> (HTTP 500) (Request-ID: req-e6c0d966-c7ec-4f20-8e9f-c788018a8d81) I explored the openstack installation myself, just wondering if there is any online hands-on training or course that I can enroll in? Thanks. Kind regards, Walsh

1 0

[neutron] Multi-AZ without L2 spanning between datacenter for external network
by Steve Vézina 06 Nov '20

06 Nov '20

Hi everyone, I am wondering if anyone got a multi-az deployment using OVS that work with seperate network fabrics which mean no L2 spanning between the AZs for external network? Thanks! Steve.

1 0

[tripleo][ci] ubi-8:3 has broken all centos-8 tripleo jobs
by Wesley Hayutin 05 Nov '20

05 Nov '20

Greetings, Bug: https://bugs.launchpad.net/tripleo/+bug/1902846 Patch: https://review.opendev.org/#/c/761463 Status: RED Thanks to Sagi and Sandeep ( ruck / rovers ) the issue was caught yesterday. Few iterations on where and how to pin this back to a working ubi-8 image for containers builds. We are confident the current patch will set things back to working. Context: https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image CentOS / RHEL ecosystem are not quite in sync yet.

1 1

ovs-dpdk bonding question
by Satish Patel 05 Nov '20

05 Nov '20

Folks, I have a compute node with only 2x10G port in that case, how do I configure ovs-dpdk with bonding support? I can understand if i have more than 2 nic ports then i can make one of nic port to management but in my case i have only two. Does that mean I can't utilize bonding features, is that true? How do other folks deal with this kind of scenario? (my deployment tool is openstack-ansible) ~S

1 0

[glance] Single store support removal
by Abhishek Kekane 05 Nov '20

05 Nov '20

Hi All The Single store glance support(default) was deprecated in Rocky release by Change-Id: I50189862454ada978eb401ec24a46988517ea73b The glance team will start working on removing single store support from the wallaby cycle and intended it to finish the same in wallaby or during milestone 1 of the next cycle. Below is the roadmap for removing single store configuration support from glance and glance_store repository. 1. Default Glance to configure multiple stores - Wallaby milestone 1 - https://review.opendev.org/#/c/741802/ 2. Convert single store unit and functional tests to use multiple stores - Wallaby milestone 1 3. Remove use of single store from glance - Wallaby milestone 2 4. Remove single stores support from glance_store - Wallaby milestone 3 to X milestone 1 We would like to encourage our users to start moving to multiple stores of glance if you are still using traditional single stores of glance in your deployments. Please let us know if you have any queries or suggestions about the same. Thank you, Abhishek

1 0

Openstack - File system changing to read-only mode
by ANUSUYA MANI 05 Nov '20

05 Nov '20

Openstack - File system changing to read-only mode after 1 or 2 days of creating the instance. Not able to access any files after that. I am using Ubuntu 18.04 instances. I have installed openstack on my server which is also ubuntu 18.04. I have enough disk space. After this issues, when i try to remount , i am not able to do. what is the cause of this kind of issue and how to resolve this. Kindly help me in resolving this. Attaching logs here.

2 1

[manila][ptg] Manila Wallaby PTG Summary
by Goutham Pacha Ravi 04 Nov '20

04 Nov '20

Hello Zorillas and all other interested Stackers! The OpenStack Manila Project Technical Gathering for the Wallaby development cycle was a successful meeting of project developers, users, operators and contributors to the rest of OpenStack, Kubernetes, Ceph and other communities - simply all zorillas and friends! I would like to thank the PTG organizing committee, (the Kendalls! :D) the infrastructure team, and everyone that contributed to the discussions. The following is my summary of the proceedings. I've linked associated etherpads, and resources to dig in further, and chat with us here, or on freenode's #openstack-manila! == Day 1 - Oct 26, 2020, Mon == === Manila Interop testing === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-interop Discussion Items: - OSF Foundation Board and Interop Working Group members were apprised about Manila, its capabilities and problem space - Manila contributors answered questions regarding user workflows, tempest integration, vendor coverage and project maturity - Manila's addition to the Interop refstack suite will allow: * OpenStack clouds and distributions to certify their manila APIs for the "OpenStack Powered" trademark program, as well as, * OpenStack Manila third party integrations can claim the "OpenStack Compatible" label - A plan was charted to target an upcoming interop advisory with manila as an "Add-On" component - Interop team presented their idea for E2E testing for running container workloads on top of openstack Actions: - Vida Haririan (vhari), Liron Kuchlani (lkuchlan) and Goutham Pacha Ravi (gouthamr) will create the interop test plan for Manila - Test plan target is the upcoming 2020.10 advisory === Manila Retrospective === Topic Etherpad: https://etherpad.opendev.org/p/manila-victoria-retrospective Discussion Items: - Victoria Cycle Bug/Documentation Squash days were a big hit. 45% of the bug backlog was addressed with these squashes - thanks vhari/vkmc! - Team's doing a great job of farming low-hanging-fruit; but resolution is taking longer, we should timebox fixes for Medium prio low-hanging-fruit; high prio bugs cannot be tagged "low-hanging-fruit" - Team recognized the mentorship eagerness, and the opportunity providers in Victoria/Wallaby - Grace Hopper Celebration, Outreachy, Boston University Project and other venues - We couldn't complete the "migrate to focal fossa goal" - team was short handed at the end of the release, thanks to the goal champion, Ghanshyam Mann for ensuring we can make decent progress and target completion in wallaby - New TC tags (kubernetes-in-virt, assert:supports-accessible-upgrade, erstwhile tc:approved-release) were great, more to come in Wallaby (vulnerability-managed, supports-api-interoperability) - A GREAT DEAL of work was done on manila-tempest-plugin, and the team is thankful, and is sure users are appreciative of the focus we have on CI. - Great PTL leadership - but there's room to grow :D - Collaborative review sessions are a hit. Let's keep doing them! Actions: - We'll have a bug squash event closer to Wallaby-1 for bigger bugs that require API/DB changes as identified in the last Cycle (vkmc/vhari) - We'll have Bug/Documentation Squash after Wallaby-3 as well - Work on TC tags by Wallaby-1 - Contributors can actively seek Collaborative Review sessions for the work they're doing - CI flakiness needs to be audited and recurring test failures will be identified (dviroel) and discussed at an upcoming IRC meeting - Backend Feature Support Matrix will be improved and doc bugs will be filed for other issues identified (dviroel) === Cephadm, Triple-O and NFS-Ganesha === Topic Etherpad: https://etherpad.opendev.org/p/tripleo-ceph Discussion Items: - fultonj/gfidente/fpantano presented three specs to chart the future of ceph deployment with tripleo. The ceph community will no longer support ceph-ansible as a deployment tool. - particularly interesting to the manila team was the fate of nfs-ganesha ("ceph-nfs") which doesn't have adequate support in ceph's new deployment tooling (cephadm and ceph orch) to cover tripleo's requirements of HA, or allow deployment flexibility like ceph-ansible used to (ceph-ansible would allow deploying nfs-ganesha as a standalone service on tripleo hosts) - the proposal was to retain the portions of ceph-ansible that were used for nfs-ganesha in tripleo while replacing the use of ceph-ansible with cephadm/ceph orch. - tripleo contributors were concerned about the future supportability of taking over the portion of the setup that ceph ansible does for tripleo today; they would be more comfortable if cephadm can be fixed in time for wallaby, or the portions of the code taken from ceph-ansible be in an independent repo Actions: - pursue cephadm/orch support for nfs-ganesha with ceph-orchestration team and understand timeline and upgrade implications when substituting the work - advance the work via specs == Day 2 - Oct 27, 2020, Tue == === Sub teams === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-subteams Discussion Items: - gouthamr/vkmc proposed that client repos (python-manilaclient, manila-ui) and tempest (manila-tempest-plugin) have their own core teams - manila-core can be part of the initial core teams of those repos - the idea is to create focussed subteams that can to some degree of autonomy, govern these projects with the domain knowledge they have, have independent meetings and bug triages if they wish and dictate a roadmap - this way, review bandwidth can be adequately shared - the sub teams will allow manila core team mentoring efforts and provide an easier on ramp for new maintainers - team agreed that this is a good way forward, and acknowledged that they would not want to create more maintenance burden or create silos. Actions: - get https://review.opendev.org/758868/ merged - to avoid siloing, weekly IRC meeting will call upon subteams to share updates - focussing on a sub project doesn't mean we don't pay attention to other repos - attempt to record mentoring sessions and post it publicly for posterity === Extending shares via the Manila scheduler === Topic Etherpad: https://etherpad.opendev.org/p/share-stuck-in-extend-discussion Discussion Items: - manila share extension currently doesn't go through the scheduler - they directly hit the share service/host responsible for the share ( https://bugs.launchpad.net/manila/+bug/1855391) - this needs to be fixed for two reasons - a) capacity based calculations are off if scheduler is ignored, b) service health checks are not accounted for - there was a concern this change would break administrators that rely on this wrong behavior as storage pools fill up - this was called out as a corner case, and instead of having a global way to opt-in/out of using the scheduler for share extensions, we can build a "force" flag for privileged users that will preserve existing behavior Actions: - haixin will propose changes to the patch based on this feedback === Virtio-FS === Topic Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-vptg-october-2… Discussion Items: - virtiofs support has debuted in newer linux kernels and the libvirt/qemu/kvm communities have adopted it - in OpenStack, Nova can be made to use virtio-fs and expose Manila shares to tenant VMs - this provides a user experience improvement for manila users where mount automation has been a concern for a while, along with the desire to have strong multi-tenant separation on the network path which only a subset of manila backends are able to provide directly - virtiofs support does not replace DHSS=True or use of gateways like NFS-Ganesha (e.g.: CephFS, GPFS, etc) since those are still very much valuable when the consumer isn't nova VMs but baremetals, containers or non-OpenStack VMs. - nova team helped understand the feature submission process and provided guidance on how to integrate this feature in stages - the user experience, data models and cross service RPCs for this can be modeled around block device mapping, however we don't need to share or copy the implementation - this is surely a large multi-cycle work - nova team suggested that we begin with only attach/detach workflows in Wallaby Actions: - tbarron will propose a nova spec to allow "nova attach fs" (and detach) workflows - we'll continue to design "boot with share" or "boot from share" APIs, including scheduler changes through this cycle === Share Server Updates === Topic Etherpad: https://etherpad.opendev.org/p/share-server-update Discussion Items: - objective is to be able to update security services and share network subnets after share servers have been provisioned - users that want to make these updates have no access to share servers - a security service update can impact multiple share networks (and hence multiple share servers) and in turn multiple share resources, so there was a concern with granularity of the update - operators don't want to be involved with the updates, want users to be able to make the updates on resources they can see (security services or share networks) - if we allow end users to make these changes, we'll still need to break down the operation into more granular bits, and provide APIs to perform validation and multi-step updates Actions: - dviroel will propose spec updates based on the feedback gathered here: https://review.opendev.org/729292 - need other DHSS=True driver maintainers to pay attention to these changes === Share Affinity Hints === Topic Etherpad: https://etherpad.opendev.org/p/manila-anti-affinity Discussion Items: - need a way to specify affinity or anti-affinity placement hints wrt existing resources (e.g: shares, share groups) - share groups provide a way to indicate affinity, but they may also encase shares into a construct and make individual operations on shares harder (you cannot add existing shares to a group or remove shares from a share group without deleting them, you can only create new members in a share group) - need a vehicle other than groups or share type extra specs to carry scheduling decisions that affect single shares - this mechanism shouldn't break cloud storage abstraction - cinder has had the ability for end users to add placement hints for affinity without breaking abstractions Actions: - carthaca will propose a specification for this work - we'll seek reviews from cinder contributors on the spec == Day 3 - Oct 28, 2020, Wed == === Responsibility for Code Reviews === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - a bulk of the day-2 operations that are being enhanced have significant impact on vendor driver implementations - we do have first party "reference" driver support for testing and designing manila APIs in a generic fashion but, not having vendor driver maintainer feedback is unfortunate - operator feedback is also very much appreciated, and we've made significant decisions because of it Actions: - proposers for new features that affect drivers must actively seek out vendor driver maintainers and operators and add them to review. The team will help identify these individuals - we'll track vendor/operator feedback and reviews as part of the review focus tracking we do through the cycle === Acting on Deprecation removals === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - tbarron proposed https://review.opendev.org/745206/ to remove old deprecated config options from manila - we should be doing this more actively each cycle, however, we held off from merging the code change above considering the impact to configuration and deployment tooling - driver module maintainers must adjust the deployment tooling/other usages accordingly asap Actions: - dviroel, carloss and gouthamr will review and merge https://review.opendev.org/745206/ === rootwrap-to-privsep migration === Topic Etherpad: https://etherpad.opendev.org/p/manila-migration-from-rootwrap-to-privsep Discussion Items: - this has been selected as a community goal for Wallaby - privsep has not been used in manila so far - most first party and reference drivers (lvm, zfsonlinux, generic, container, ceph) use rootwrap heavily - some third party drivers also use rootwrap - team was concerned with the completion criteria wrt third party drivers - a stretch goal would be to investigate if dropping privileges for operations by substituting mechanisms is possible Actions: - carloss will work on this goal, no specification is necessary - adequate testing, admin/operator documentation will be provided - carloss will reach out to the third party driver maintainers to act on rootwrap removals - carloss/team will attack de-escalation/removing use of root privs to perform an operation, opportunistically === Secure RBAC improvements === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-policy-changes Discussion Items: - manila will need to support splitting of the existing admin, member roles to system, domain and project admins and members - operators can define personas with these default roles using keystone's "role scope" - an accompanying feature is to provide "reader" role permissions as well - manila accepts the use of "policy.yaml" to drive RBAC, over "policy.json", but, the default is still "policy.json" and this needs to change due to several challenges, including the ability to have comments in the files Actions: - gouthamr will propose a spec for policy refresh across manila APIs/resources using these new role personas - making policy.yaml the default for policy overrides is going to be a community goal. We're targeting this transition to wallaby-1 in manila - we'll attempt to complete this effort in wallaby. there are several parts, collaboration is welcome! === CephFS Updates === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-cephfs-driver-update Discussion Items: - vkmc provided an update on the cephfs feature roadmap - we need changes in cephfs (preferably in ceph-nautilus) to perform authorization, subvolume cloning, capacity reporting etc. This work is being tracked through tracker tickets in Ceph's tracking system - we stopped using shaman builds for ceph and nfs-ganesha in victoria cycle - consuming nfs-ganesha from ppa's has introduced new scenario test failures, vkmc is currently triaging them Actions: - start testing ceph octopus in the wallaby cycle - keep momentum on the ceph trackers and switch over from ceph-volume-client to ceph-mgr and implement create share from snapshot in the cephfs drivers - engage with ceph and nfs-ganesha communities to create a support matrix across nfs-ganesha versions, manila and cephfs === Divisive Language Correction === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - spotz joined us, and recapped the diversity and inclusion wg's work so far - manila team is determined to help resolve any divisive language and references in code and documentation - the team realizes that unconscious use of negative language is affecting the community's inherent desire to be welcoming and inclusive - no manila architecture or code references currently *need* the use of the divisive words identified by the working group and the wider openstack community - making changes is important to us, but we recognize it's just part of the story Actions: - we'll begin with a documentation change to remove the words identified in https://etherpad.opendev.org/p/divisivelanguage - we'll wait to coordinate a change of name for the development/trunk branch, and other "upstream" changes to databases, git, opendev - team actively welcomes any feedback == Day 5 - Oct 30, 2020, Fri == === Share and Server Migration graduation === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - we've graduated one major feature through the last couple of cycles, share migration is next - team agreed to keep share server migration as experimental APIs since they haven't had sufficient soak time - no significant changes have been made to share migration migration APIs since Ocata, leading to believe the APIs are stable and can be improved via microversions where necessary - not a lot of vendor driver implementations for driver optimized migration, NetApp driver only allows moving within a backend at the moment - generic migration improvements have been deprioritized, and need help in terms of High Availability of the Data service as well as providing a jobs table to track, and coordinate ongoing migrations - tests are being skipped at the gate because of flakiness Actions: - team will get in touch with third party vendors and guage interest in implementing driver optimized migration (or testing/supporting generic migration with their drivers) (carloss). Feedback from the vendors will drive our decision to graduate the share migration APIs in Wallaby. === Metadata for all share resources === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-metadata-controller Discussion Items: - the proposal is to introduce a metadata API controller that can be inherited by the resource controllers - all user facing resources will have metadata capabilities, with consistent API methods - this is expected to benefit automation use cases, manila-csi and the upcoming virtio-fs effort Actions: - gouthamr will propose the spec for team's review, including identifying the resources that will be targeted in the Wallaby release - share metadata APIs will be improved to adhere to the API SIG spec: https://specs.openstack.org/openstack/api-sig/guidelines/metadata.html === Client Project updates === Topic Etherpads: https://etherpad.opendev.org/p/manila-osc-wallaby-ptg and https://etherpad.opendev.org/p/manila-ui-wallaby-ptg Discussion Items: - the team met with Nicole Chen, Ashley Rodriguez, Mark Tony from Boston University who will be working on the OpenStackSDK integration for Manila APIs - maaritamm provided an update on the OSC plugin interface implementation - vkmc provided an update on manila-ui feature gaps and the upcoming Outreachy internship Actions: - for some OSC plugin command implementations, we'll benefit from integrating with OpenStackSDK rather than manilaclient SDK, so we'll coordinate that work - maaritamm/vkmc will send an email to openstack-discuss to prioritize the commands left to implement in the OSC plugin - vkmc will drive consistency across cinder/manila for the user messages dashboards that were added in Victoria - we'll continue to work on closing the feature gap in manila-ui === Manila CSI Wallaby roadmap === Topic Document: https://docs.google.com/document/u/1/d/1YJcv0EROWzYbV_8DM3DHVvDqdhlPhYRV8Np… Discussion Items: - users of manila-csi today deploy one driver per share protocol - future work on monitoring, common node plugin interactions requires us to rework the architecture to have one driver multiplex with multiple share protocol node plugins - upgrade impact as well as UI/UX impact was discussed and gman0 has documented them - share metadata is necessary to tag and identify shares Actions: - gman0 has started working on the code patches, and will benefit from reviews - mfedosin will take a look at the upgrade impact and share details for automation that can be done in the csi-operator - mfedosin will test gman0's latest patch to add share metadata via the storage class (as will folks from CERN) and provide feedback Thanks for reading thus far, there were a number of items that we couldn't cover, that you can see on the PTG Planning etherpad [1], if you own those topics, please add them to the weekly IRC meeting agenda [2] and we can go over them. The master meeting minutes document is available as well [3]. As usual, the whole PTG was recorded and posted on the OpenStack Manila Youtube channel [4] We had a great turn out and we heard from a diverse set of contributors, operators, interns and users from several affiliations and time zones. On behalf of the OpenStack Manila team, I deeply appreciate your time, and help in keeping the momentum on the project! [1] https://etherpad.opendev.org/p/wallaby-ptg-manila-planning [2] https://wiki.openstack.org/wiki/Manila/Meetings [3] https://etherpad.opendev.org/p/wallaby-ptg-manila [4] https://www.youtube.com/playlist?list=PLnpzT0InFrqATBbJ60FesKGYRejnTIoCW

1 0

[gate][all] assorted tempest jobs fail when IPv4 default route is not available
by melanie witt 04 Nov '20

04 Nov '20

Hi all, We have a gate bug [1] where if a CI VM does not have an IPv4 default route configured, the job will fail with one of the following errors: "[ERROR] /opt/stack/devstack/functions-common:230 Failure retrieving default route device" [2] or "[ERROR] /opt/stack/devstack/functions-common:104 Failure retrieving default IPv4 route devices" [3] because the die_if_not_set is being triggered. Most of the time, CI VMs come configured with an IPv4 default route but something changed recently (around Oct 23 or 24) to where we often get VMs that do not have an IPv4 default route configured and presumably only have an IPv6 default route. According to this logstash query [4] we have: 58 hits in the last 7 days, check and gate, all failures, all on the limestone-regionone node provider, various projects, various jobs Nate Johnson has proposed a fix here: https://review.opendev.org/761178 Reviews appreciated. Cheers, -melanie [1] https://bugs.launchpad.net/devstack/+bug/1902002 [2] example: https://zuul.openstack.org/build/7543021732cc4886b608553da58e81f9/log/contr… [3] example: https://zuul.opendev.org/t/openstack/build/7fff839dd0bc4214ba6470ef40cf78fd… [4] http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:…

1 0

Editing libvirt xml file
by vladimir franciz blando 04 Nov '20

04 Nov '20

Hi, I edited the libvirt xml (virsh edit...) file of a running Windows server instance because I changed the video model type from cirrus to vmvga so it can support a higher resolution on a console (cirrus supports up to 1280 only). After editing, i "soft-rebooted" the instance and the new configuration sticks. That's awesome. But when you do a "hard-reboot" it will revert back to the original config. I also tried to do a "shut-down" then "start" again, but it still reads the original config. Not sure where it is reading the config from... Regards Vlad

3 5

[neutron][ovn] Neutron <-> OVN DB synchronization code
by Piotr Misiak 04 Nov '20

04 Nov '20

Hi, Do you know why Neutron <-> OVN DB sync code synchronizes "DEVICE_OWNER_ROUTER_HA_INTF" router ports here in this line: https://github.com/openstack/neutron/blob/164f12349fd8be09b9fd4f23b8cf8d2f3… ? As far as know there is no need for HA network ports for L3 virtual routers implementation in OVN, because OVN uses the internal BFD mechanism for Gateway Chassis reachability tests. Thanks, Piotr

1 0

[kolla] Kolla klub meetings paused
by Mark Goddard 04 Nov '20

04 Nov '20

Hi, We agreed at the PTG to try rebooting the Kolla klub meetings at a different time to involve some new members. Let's pause the meetings until then. Regards, Mark

1 0

[tripleo] next meeting Tuesday Nov 10 @ 1400 UTC in #tripleo
by Marios Andreou 04 Nov '20

04 Nov '20

Hello tripleo as discussed at PTG - we voted [1] to have IRC meetings every 2 weeks and next week will be 2 weeks since PTG :) Keeping the same day and time our next meeting will be ** Tuesday 10th November at 1400 UTC in #tripleo. ** Our regular agenda is at https://wiki.openstack.org/wiki/Meetings/TripleO Please add items you want to raise at https://etherpad.opendev.org/p/tripleo-meeting-items . There were concerns voiced at PTG about low attendance in these meetings but at the same time quite a few folks voted to have it. So, let's try again and as with all the things we will re-evaluate based on all our feedback, Can I get a o/ if you plan on attending these meetings? Or even if you can't but plan to read the meetbot logs ;) Obviously now would be a good time to speak up if you hate tuesdays at 1400 UTC and want to propose some alternative for us to consider, thanks, marios [1] https://etherpad.opendev.org/p/tripleo-ptg-wallaby-community-process

1 0

[ptl] Victoria Release Community Meeting
by helena＠openstack.org 04 Nov '20

04 Nov '20

Hi Everyone, We are looking to do a community meeting following The Open Infrastructure Summit and PTG to discuss the Victoria Release. If you’re a PTL, please let me know if you’re interested in doing a prerecorded explanation of your project’s key features for the release. We will show a compilation of these recordings at the community meeting and follow it with a live Q&A session. Post community meeting we will have this recording live in the project navigator. Cheers, Helena

8 10

[cinder] Block Storage API v2 removal
by Brian Rosmaita 04 Nov '20

04 Nov '20

The Block Storage API v2 was deprecated in the Pike release by Change-Id: I913c44799cddc37c3342729ec0ef34068db5b2d4 The Cinder team will be removing it during the Wallaby development cycle. At the Wallaby PTG, the question came up about Block Storage API v2 support in the python-cinderclient. We looked at some proposals [0] at today's Cinder meeting and plan to make a decision at next week's meeting [1]. If you have strong feelings about this issue, please make them known on the etherpad [0], the ML, or by attending the next Cinder meeting (1400 UTC in #openstack-meeting-alt on Wednesday 11 November). [0] https://etherpad.opendev.org/p/python-cinderclient-v2-support-removal [1] https://etherpad.opendev.org/p/cinder-wallaby-meetings

1 0

[tc] weeklu update
by Mohammed Naser 04 Nov '20

04 Nov '20

Hi everyone, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Adding reno and warnings example for JSON->YAML goal doc https://review.opendev.org/760956 - Select JSON to YAML goal for Wallaby cycle https://review.opendev.org/760957 - Add goal for migrate RBAC policy format from JSON to YAML https://review.opendev.org/759881 - Add diablo_rojo liaison preferences https://review.opendev.org/759718 - Add danms liaison preferences https://review.opendev.org/758822 - Add ricolin liaison preferences https://review.opendev.org/759704 - Add gmann liaison preference https://review.opendev.org/758602 - Resetting projects' TC liaisons empty https://review.opendev.org/758600 - Move Placement under Nova's governance https://review.opendev.org/760917 - Clarify the requirements for supports-api-interoperability https://review.opendev.org/760562 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/759904 ## General Changes - Implement distributed leadership in tools and schema https://review.opendev.org/757966 - Adding missing IRC nick https://review.opendev.org/759724 - Update dansmith IRC nick https://review.opendev.org/760561 - Update projects with Telemetry PTL election result https://review.opendev.org/760206 - Appoint XueFeng Liu as Senlin PTL https://review.opendev.org/758122 - Begin the 'X' release naming process https://review.opendev.org/759888 - Appoint Adam Harwell as Octavia PTL https://review.opendev.org/758121 - Add nomination for TC chair https://review.opendev.org/758181 - Appoint Rafael Weingartner as CloudKitty PTL https://review.opendev.org/758120 - Appoint Frode Nordahl as OpenStack Charms PTL https://review.opendev.org/758119 - Select Privsep as the Wallaby Goal https://review.opendev.org/755590 ## Project Updates - Adopting the DPL governance model for oslo https://review.opendev.org/757906 Thanks for reading! Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

Random 503 error while running using api/command line
by Deepa KR 04 Nov '20

04 Nov '20

Hi All Good Day We have a Train Openstack setup using juju maas configured in HA with 3 controllers. When using the openstack api getting a timeout error randomly. Also sometimes getting "Unknown Error (HTTP 503)" or Remote end closed connection without response while using the command line . openstack server list --all-projects *Unknown Error (HTTP 503)* Kindly suggest to look in the right direction. Regards, Deepa K R

1 0

[tripleo][ci] Monday Nov 2
by Wesley Hayutin 04 Nov '20

04 Nov '20

Greetings, The tripleo ci team has identified a handful of patches that we'd like to land prior to Nov 2, the day docker.io goes away. We've hit some new bugs and have also tuned a few things to try and make sure we can get patches to merge. Our current focus is across master, victoria, ussuri and centos-8 train, and queens while reducing coverage in rocky and stein. A list of the prioritized gerrit reviews can be found here: https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view The entire topic can be found here: https://review.opendev.org/#/q/topic:new-ci-job Thanks all.

4 4

[nova] Why nova needs password-less SSH to do live migraiton?
by Zhi CZ Chang 04 Nov '20

04 Nov '20

3 5

[ironic] Configuration mold follow-up
by Jaunteva, Aija 04 Nov '20

04 Nov '20

Hi, to follow up on Ironic PTG session about Configuration molds [1] I'm scheduling a call to discuss remaining items (mainly storage of the molds). Anyone interested please add your availability in Doodle [2]. When time slot decided, will share call details. Regards, Aija [1] https://etherpad.opendev.org/p/ironic-wallaby-ptg line 216 [2] https://doodle.com/poll/dry4x5tbmhi6x6p3

2 3

[Neutron] PTG summary
by Slawek Kaplonski 04 Nov '20

04 Nov '20

Hi, Below is my summary of the Neutron team sessions which we had during the virtual PTG last week. Etherpad with notes from the discussions can be found at [1]. ## Retrospective of the Victoria cycle >From the good things during _Victoria_ cycle team pointed: * Complete 8 blueprints including the _Metadata over IPv6_ [2], * Improved feature parity in the OVN driver, * Good review velocity >From the not so good things we mentioned: * CI instability - average number of rechecks needed to merge patch in last year can be found at [3], * Too much "Red Hat" in the Neutron team - and percentage of the reviews (and patches) done by people from Red Hat is constantly increasing over last few cycles. As a main reason of that we pointed that it is hard to change companies way of thinking that dedicating developer to the upstream project means that they lose developer in downstream. * Migration of our CI and Zuul v3 took us a lot of time and effort - but good thing is that we accomplished that in the Victoria cycle :) During that session we also agreed on some action items for the Wallaby cycle: * keep talking about OVN details - Miguel Lavalle and me will work on some way to deliver talks about Neutron OVN backend and OVN internals to the community during next months. The idea is to maybe propose some talks ever 6 weeks or so. This may make ovn driver development more diverse and let operators to thing about migration to the ovn backend. ## Review of the existing meetings We reviewed list of our existing upstream meetings and discussed about ideas on how to increase number of attendees on the meetings. We decided to: * drop neutron-qos meeting as it's not needed anymore * advertise more meetings and meetings' agenda on the OpenStack mailing list - I will send reminders with links to the agenda before every meeting * Together with Lajos Katona we will give some introduction to the debugging of CI issues in Neutron* ## Support for old versions Bernard started discussion about support for the old releases in Neutron and Neutron stadium projects. For Neutron we decided to mark __Ocata__ branch as unmaintained already as its gate is already broken. For the __Pike__ and never branches we will keep them in the __EM__ phase as there is still some community interest to keep those branches open. For the stadium projects we decided to do it similary to what we did while looking for new maintainers for the projects. We will send email "call for maintainers" for such stable branches. If there will be no voluneers to step in, fix gate issues and keep those branches healthy, we will mark them as __unmaintained__ and later as __End of Life__ (EOL). Currently broken CI is in projects: * networking-sfc, * networking-bgpvpn/bagpipe, * neutron-fwaas And those are candidates to be marked as unmaintained if there will be no volunteers to fix them. Bernard Cafarelli volunteered to work on that in next days/weeks. ## Healtcheck API endpoint We discussed as our healtcheck API should works. During the discussion we decided that: * healtcheck result should __NOT__ rely on the agents status, it should rely on worker's ability to connect to the DB and MQ (rabbitmq) * Lajos will ask community (API experts) about some guidance how it should works on the whole OpenStack level, * As for reference implementation we can check e.g. Octavia [4] and Keystone [5] which already implemented it. ## Squash of the DB migration script Rodolfo explained us what are benefits of doing such squash of the db migration scripts from the old versions: * Deployment is faster: we don't need to create/delete tables or create+update other ones - the win is small possibly in the magnitude of 5s per job, * DB definition is centralized in one place, not in original definition plus further migrations - that is most important reason why we really should do that, * UTs faster: removal of some older checks. The problem with this may be that we need to do that carefully and be really verbose about with such changes we may break stadium projects or 3rd party projects which are doing db migration too. To minimalize potential breakage, we will announce such changes on the OpenStack discuss mailing list. Rodolfo volunteered to take propose squash up to Liberty release in W cycle. Together with this squash we will also document that process so in next cycles we should be able to do squashes for newer releases in easier way. Lajos volunteered to help with fixing Neutron stadium projects if that will be needed. ## Switch to the new engine facade We were discussing how to move on and finally finish old Blueprint [6]. We decided that together with Rodolfo we will try how this new engine facade will work without using transaction guards in the code. Hopefully that will let us move on with this. If not, we will try to reach out to some DB experts for some help with this. ## Change from rootwrap to the privsep This is now community goal during the Wallaby cycle so we need to focus on it to accomplish that transition finally. This transition may speed up and make our code a bit more secure. Rodolfo explained us multiple possible strategies of migration: * move to native, e.g. * replace ps with python psutils, not using rootwrap or privsep * replace ip commands with pyroute2, under a privsep context (elevated permissions needed) * directly translate rootwrap to privsep, executing the same shell command but under a privsep context To move on with this I will create list of the pieces of code which needs to be transitioned in the Neutron repo and in the stadium projects. Current todo items can be found on the storyboard [7]. ## Migration to the NFtables During this session we were discussing potential strategies on how to migrate from the old iptables to the new nftables. We need to start planning that work as it major Linux distributions (e.g. RHEL) are planning to deprecate iptables in next releases. It seems that currently all major distros (Ubuntu, Centos, OpenSuSE) supports nftables already. We decided that in Wallaby cycle we will propose new _Manager_ class and we will add some config option which will allow people to test new solution. In next cycles we will continue work on it to make it stable and to make upgrade and migration path for users as easy as possible. There is already created blueprint to track progress on that topic [8]. We need to migrate: * Linuxbridge firewall, iptables OVS hybrid firewall, * L3 code (legacy router, DVR router, conntrack, port forwarding), * iptables metering, * metadata proxy, * dhcp agent for when it does metadata for isolated networks and namespace creation, * neutron-vpnaas - ipsec code, * and maybe something else what we didn't found yet. ## Nova-Neutron cross project session We had very interesting discussion with Nova team. We were discussing topics like: * NUMA affinity in the neutron port * vhost-vdpa support * default __vnic_type__/__port flavour__ Notes from that discussion are available in the nova's etherpad [9]. ## Neutron scalling issues At this session we were discussing issues mentioned by operators on the Forum sessions a week before the PTG. There was couple of issues mentioned there: * problems with retries of the DB operations - we should migrate all our code to the oslo.db retries mechanism - new blueprint [10] is created to track progress on that one. * problems with maintenance of the agents, like e.g. DHCP or L3 agents - many of those issues are caused by how our agents are designed and to really fix that we would need very deep and huge changes. But also many of those issues can be solved by the __ovn__ backend - **and that is strategic direction in which neutron wants to go in the next cycles**, * Miguel Lavalle and I volunteered to do some profiling of the agents to see where we are loosing most of the time - maybe we will be able to find some _low hanging fruits_ which can be fixed and improve the situation at least a bit, * Similar problem with neutron-ovs-agent and especially security groups which are using _remove group id_ as a reference - here we also need some volunteers who will try to optimize that. ## CI (in)stablility On Thursday we were discussing how to improve our very poor CI. Finally we decided to: * not recheck patches without giving reason of recheck in the comment - there should be already reported bug which should be linked in the _recheck_ comment, or user should open new one and link to it also. IN case if the problem was e.g. related to infra some simple comment like _infra issue_ will also be enough there, * To lower number of existing jobs we will do some changes like: * move *-neutron-lib-master and *-ovs-master jobs to the experimental and periodic queues to not run them on every patch, * I will switch _neutron-tempest-plugin-api_ job to be deployed with uwsgi so we can drop _neutron-tempest-with-uwsgi_ job, * Consolidate _neutron-tempest-plugin-scenario-linuxbridge_ and _neutron- tempest-linuxbridge_ jobs, * Consolidate _neutron-tempest-plugin-scenario-iptables_hybrid and _neutron- tempest-iptables_hybrid jobs, Later we also discussed about the way how to run or skip tests which can be only run when some specific feature is available in the cloud (e.g. _Metadata over IPv6_). After some discussion we decided to add new config option with list of enabled features. It will be very similar to the existing option _api_extensions_. Lajos volunteered to work on that. As last CI related topic we discussed about testing DVR in our CI. Oleg Bondarev volunteered to check and try to fix broken _neutron-tempest-plugin- dvr-multinode-scenario_ job. ## Flow based DHCP Liu Yulong raised topic about new way of doing fully distributed DHCP service, instead of using _DHCP agent_ on the nodes - RFE is proposed at [11]. His proposal of doing Open Flow based DHCP (similar to what e.g. ovn-controller is doing) is described in [12]. It could be implemented as an L2 agent extension and enabled by operators in the config when they would need it. As a next step Liu will now propose spec with details about this solution and we will continue discussion about it in the spec's review. ## Routed provider networks limited to one host As a lost topic on Thursday we briefly talked about old RFE [13]. Miguel Lavalle told us that his company, Verizon Media, is interested in working on this RFE in next cycles. This also involves some work on Nova's side which was started by Sylvain Bauza already. Miguel will sync with Sylvain on that RFE. ## L3 feature improvements On Friday we were discussing some potential improvements in the L3 area. Lajos and Bence shown us some features which their company is interested in and on which they plan to work. Those are things like: * support for Bidirectional Forwarding Detection * some additional API to set additional router parameters like: * ECMP max path, * ECMP hash algorith * --provider-allocation-pool parameter in the subnets - in some specific cases it may help to use IPs from such _special_ pool for some infrastructure needs, more details about that will come in the RFE in future, For now all those described above improvements are in very early planning phase but Bence will sync with Liu and Liu will dedicate some time to discuss progress on them during the __L3 subteam meetings__. ## Leveraging routing-on-the-host in Neutron in our next-gen clusters As a last topic on Friday we were discussing potential solutions of the _L3 on the host_ in the Neutron. The idea here is very similar to what e.g. __Calico plugin__ is doing currently. More details about potential solutions are described in the etherpad [14]. During the discussion Dawid Deja from OVH told us that OVH is also using very similar, downstream only solution. Conclusion of that discussion was that we may have most of the needed code already in Neutron and some stadium projects so as a first step people who are interested in that topic, like Jan Gutter, Miguel and Dawid will work on some deployment guide for such use case. ## Team photo During the PTG we also made team photos which You can find at [15]. [1] https://etherpad.opendev.org/p/neutron-wallaby-ptg [2] https://blueprints.launchpad.net/neutron/+spec/metadata-over-ipv6 [3] https://ibb.co/12sB9N9 [4] https://opendev.org/openstack/octavia/src/branch/master/octavia/api/ healthcheck/healthcheck_plugins.py [5] https://docs.openstack.org/keystone/victoria/admin/health-check-middleware.… [6] https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch [7] https://storyboard.openstack.org/#!/story/2007686 [8] https://blueprints.launchpad.net/neutron/+spec/nftables-migration [9] https://etherpad.opendev.org/p/nova-wallaby-ptg [10] https://blueprints.launchpad.net/neutron/+spec/oslo-db-retries [11] https://bugs.launchpad.net/neutron/+bug/1900934 [12] https://github.com/gotostack/shanghai_ptg/blob/master/ shanghai_neutron_ptg_topics_liuyulong.pdf [13] https://bugs.launchpad.net/neutron/+bug/1764738 [14] https://etherpad.opendev.org/p/neutron-routing-on-the-host [15] http://kaplonski.pl/files/Neutron_virtual_PTG_October_2020.tar.gz -- Slawek Kaplonski Principal Software Engineer Red Hat

3 4

Intel 82599 dpdk support with centos8
by Satish Patel 04 Nov '20

04 Nov '20

Folks, I am trying to get dpdk working with my OVS on CentOS-8 and I am stuck here so I need advice from folks who can help me here. I have an HP c7000 chassis with ProLiant BL460c Gen9 blade. I am running CentOS-8 with following version of ovs-dpdk [root@compute-2 usertools]# ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.12.0 DPDK 18.11.2 I am using openstack-ansible to set up openvswitch with dpdk, and so far everything went well but I am stuck in the end. [root@compute-2 usertools]# ovs-vsctl add-port br-provider dpdk-0 -- set Interface dpdk-0 type=dpdk options:dpdk-devargs=0000:06:00.0 ovs-vsctl: Error detected while setting up 'dpdk-0': Error attaching device '0000:06:00.0' to DPDK. See ovs-vswitchd log for details. ovs-vsctl: The default log directory is "/var/log/openvswitch". Here is the error message. [root@compute-2 usertools]# tail -f /var/log/openvswitch/ovs-vswitchd.log 2020-11-04T02:46:31.751Z|00303|dpdk|INFO|EAL: PCI device 0000:06:00.0 on NUMA socket 0 2020-11-04T02:46:31.751Z|00304|dpdk|INFO|EAL: probe driver: 8086:10f8 net_ixgbe 2020-11-04T02:46:31.751Z|00305|dpdk|ERR|EAL: Driver cannot attach the device (0000:06:00.0) 2020-11-04T02:46:31.751Z|00306|dpdk|ERR|EAL: Failed to attach device on primary process 2020-11-04T02:46:31.751Z|00307|netdev_dpdk|WARN|Error attaching device '0000:06:00.0' to DPDK 2020-11-04T02:46:31.751Z|00308|netdev|WARN|dpdk-0: could not set configuration (Invalid argument) 2020-11-04T02:46:31.751Z|00309|dpdk|ERR|Invalid port_id=32 This is what my NIC firmware/driver [root@compute-2 usertools]# ethtool -i eno50 driver: ixgbe version: 5.1.0-k-rh8.2.0 firmware-version: 0x800008fb, 1.2028.0 expansion-rom-version: bus-info: 0000:06:00.1 [root@compute-2 usertools]# python3 ./dpdk-devbind.py --status Network devices using DPDK-compatible driver ============================================ 0000:06:00.0 '82599 10 Gigabit Dual Port Backplane Connection 10f8' drv=vfio-pci unused=ixgbe Network devices using kernel driver =================================== 0000:06:00.1 '82599 10 Gigabit Dual Port Backplane Connection 10f8' if=eno50 drv=ixgbe unused=vfio-pci I did enabled IOMMU & huge mem in grub iommu=pt intel_iommu=on hugepagesz=2M hugepages=30000 transparent_hugepage=never Not sure what is wrong here and the big question is does this NIC support DPDK or not?

1 0

In Openstack (devstack) i am able to create maximum of 3 volumes only
by ANUSUYA MANI 04 Nov '20

04 Nov '20

I have 3 volumes of 80GB each and when i try to create a volume snapshot or a new volume i am not able to do that. i get the error 'schedule allocate volume:Could not find any available weighted backend'. The volume quotas are set properly yet i am not able to create more than 3 volumes. i have attached screenshots of the volume quotas and error message. Kindly <https://i.stack.imgur.com/ThvMo.jpg> requesting to help me solve this issue.

1 0

[cinder] Wallaby PTG summary available
by Brian Rosmaita 04 Nov '20

04 Nov '20

I've posted a summary of the discussions we had last week: https://wiki.openstack.org/wiki/CinderWallabyPTGSummary Feel free to make any corrections or clarifications. Also, look through to remind yourself what actions you volunteered to perform (you can search for your IRC nick or the text ACTION). cheers, brian

1 0