August 2020 - openstack-discuss - lists.openstack.org

[horizon] horizon-integration-tests job is broken
by Ivan Kolodyazhny 01 Sep '20

01 Sep '20

Hi team, Please, do not trigger recheck if horizon-integration-tests failed like [1]: ______________ TestDashboardHelp.test_dashboard_help_redirection _______________ 'NoneType' object is not iterable While I'm trying to figure out what is happening there [2], any help with troubleshooting is welcome. [1] https://51bb980dc10c72928109-9873e0e5415ff38d9f1a5cc3b1681b19.ssl.cf1.rackc… [2] https://review.opendev.org/#/c/749011 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 1

[ops] Restructuring OSOPS tools
by Sean McGinnis 01 Sep '20

01 Sep '20

Hello everyone, We recently expanded the scope of the Ops Docs SIG to also include any ops tooling. I think it's now time to move on to the next step of actually getting some of the old tooling in place and organized how we want it. We have several semi-abandoned repos from back when there was more work being done on ops tooling. During the great rebranding, those all were moved under the x/ namespace: https://opendev.org/x/?tab=&sort=recentupdate&q=osops Since these are now owned by an official SIG, we can move this content back under the openstack/ namespace. That should help increase visibility somewhat, and make things look a little more official. It will also allow contributors to tooling to get recognition for contributing to an import part of the OpenStack ecosystem. I do think it's can be a little more difficult to find things spread out over several repos though. For simplicity with finding tooling, as well as watching for reviews and helping with overall maintenance, I would like to move all of these under a common openstack/osops. Under that repo, we can then have a folder structure with tools/logging, tools/monitoring, etc. Then with everything in one place, we can have docs published in one place that helps find everything and easily links between tools. We can also capture some metadata about the tools, and use that to reflect their state in those docs. Please let me know if there are any objects to this plan. Otherwise, I will start cleaning things up and getting it staged in a new repo to be imported as an official repo owned by the SIG. Thanks! Sean

3 2

[TripleO][Ussuri] image prepare, cannot download containers image prepare recently
by Ruslanas Gžibovskis 01 Sep '20

01 Sep '20

Hi all, I have noticed, that recently my undercloud is not able to download images [0]. I have provided newly generated containers-prepare-parameter.yaml and outputs from container image prepare providing --verbose and later beginning of --debug (in the end) [0] were there any changes? As "openstack tripleo container image prepare default --output-env-file containers-prepare-parameter.yaml --local-push-destination" have prepared a bit different file, compared what was previously: NEW # namespace: docker.io/tripleou VS namespace: docker.io/tripleomaster # OLD [0] - http://paste.openstack.org/show/rBCNAQJBEe9y7CKyi9aG/ -- Ruslanas Gžibovskis +370 6030 7030

2 1

[neutron] Team meeting - Tuesday 01.09.2020
by Slawek Kaplonski 01 Sep '20

01 Sep '20

Hi, I will be on PTO on Tuesday and I will not be able to run our team meeting. So lets cancel it this week and see You all on meeting next week. For this week there are 3 important things from me: * please check doodle: https://doodle.com/poll/2ppmnua2nuva5nyp and put there time slots which works the best for You for the PTG in October - please do that this week as next week I need to book some slots for us, * as we are close to the Victoria-3 milestone (next week) which is also feature freeze week, please focus now on reviewin patches for BPs targeted for this cycle: https://wiki.openstack.org/wiki/Network/Meetings#Blueprints * There is new bug deputy role starting this week. Please check new schedule at https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy and let me know if it don't works for You. That's all from me for this week. See You all online :) -- Slawek Kaplonski Principal software engineer Red Hat

1 0

[tc] weekly update
by Mohammed Naser 31 Aug '20

31 Aug '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. We've also included a few references to some important mailing list threads that you should check out. # Patches ## Open Reviews - Move ansible-role-XXX-hsm projects to Barbican team https://review.opendev.org/748027 - Retire the devstack-plugin-zmq project https://review.opendev.org/748731 - Retire devstack-plugin-pika project https://review.opendev.org/748730 - Add openstack-ansible/os_senlin role https://review.opendev.org/748677 - Drop all exceptions for legacy validation https://review.opendev.org/745403 - Add openstack-helm-releases to openstack-helm https://review.opendev.org/748302 - Add assert:supports-standalone. https://review.opendev.org/722399 ## Project Updates - Add etcd3gw to Oslo https://review.opendev.org/747188 ## General Changes - Update and simplify comparison of working groups https://review.opendev.org/746763 - Move towards dual office hours in diff TZ https://review.opendev.org/746167 ## Abandoned Changes - Drop requirement of 1/3 positive TC votes to land https://review.opendev.org/746711 - Move towards single office hour https://review.opendev.org/745200 # Email Threads - vPTG October 2020 Signup: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016497.h… Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

Setuptools 48 and Devstack Failures
by Clark Boylan 31 Aug '20

31 Aug '20

Hello, Setuptools has made a new version 48 release. This appears to be causing problems for devstack because `pip install -e $PACKAGE_PATH` installs commands to /usr/bin and not /usr/local/bin on Ubuntu as it did in the past. `pip install $PACKAGE_PATH` continues to install to /usr/local/bin as expected. Devstack is failing because keystone-manage cannot currently be found at the specific /usr/local/bin/ path. Potential workarounds for this include not using `pip install -e` or relying on $PATH to find the commands rather than specifying rooted paths to them. I'll defer to the QA team on how they want to address this. While we can have devstack install an older setuptools version as well, generally this is not considered to be a good idea because anyone doing pip installs outside of devstack may get the newer behavior. It is actually important for us to try and keep up with setuptools changes as a result. Fungi indicated that setuptools expected this to be a bumpy upgrade. I'm not sure if they would consider `pip install -e` and `pip install` installing to different paths as a bug, and if they did which behavior is correct. It would probably be a good idea to file a bug upstream if we debug this further. Clark

5 6

[octavia] usage of SELECT .. FOR UPDATE
by Mohammed Naser 31 Aug '20

31 Aug '20

Hi everyone, We're being particularly hit hard across different deployments where Octavia has several SELECT .. FOR UPDATE queries which are causing load balancers to fail to provision properly. - spare_pools: This usually hits on rolling restarts of o-housekeeping as they all seem to try to capture a lock -- https://github.com/openstack/octavia/blob/73fbc05386b512aa1dd86a0ed6e8455cc… - quota: This hits when provisioning a lot of load balancers in parallel. For example in cases when using Heat -- https://github.com/openstack/octavia/blob/bf3d5372b9fc670ecd08339fa989c9b73… These hurt quite a lot in a busy deployment and result in a poor user experience unfortunately. We're trying to off-load Octavia to it's own database server but that is more of a "throw power at the problem" solution. I can imagine that we can probably likely look into a better/cleaner alternative that avoids this entirely? I'm happy to try and push for some of this work on our side. Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

2 1

Openstack zun ui
by mahdi abbasi 30 Aug '20

30 Aug '20

Hi, I want install zun ui, first i installed horizon with package and then install zun ui with pip and then python horizon_path/manage.py collectstatic But i receive error in httpd finaly. Error: ImportError: No module named zun_ui Please help me Best Regards Mahdi

2 4

[all] READMEs of zuul roles not rendered properly - missing content
by Martin Kopec 30 Aug '20

30 Aug '20

Hello everyone, I've noticed that READMEs of zuul roles within openstack projects are not rendered properly on opendev.org - ".. zuul:rolevar::" syntax seems to be the problem. Although it's rendered well on github.com, see f.e. [1] [2]. I wonder if there were some changes in the supported README syntax. Also the ".. zuul:rolevar::" syntax throws errors on online rst formatters I was testing on, however, it's rendered fine by md online formatters - maybe opendev.org is more rst strict in case of .rst files than github? Any ideas? [1] https://opendev.org/openstack/tempest/src/branch/master/roles/run-tempest [2] https://github.com/openstack/tempest/tree/master/roles/run-tempest Thanks, -- Martin Kopec Quality Engineer Red Hat EMEA <https://www.redhat.com> <https://red.ht/sig>

4 4

[tc][telemetry][gnocchi] The future of Gnocchi in OpenStack
by Adrian Turjak 29 Aug '20

29 Aug '20

Hey OpenStackers, We're currently in the process of discussing what to do with OpenStack's reliance on Gnocchi, and at present it is looking like we are most likely to just fork it back under a new name (currently Farfalle to stick with the pasta theme). The discussion is mostly happening here: https://review.opendev.org/#/c/744592/ But for those running Gnocchi in prod, this is likely something you may want to know about and we'd like to hear from you. A bit of history: Gnocchi started off as a new backend for Ceilometer in OpenStack, and eventually become the defacto API for telemetry samples when that was removed from Ceilometer (as backed by MongoDB). Gnocchi was eventually spun off outside of OpenStack, but still essentially remained our API for telemetry despite not being an official part of OpenStack anymore. Since then the development around it seems to have stalled, with pull requests left unreviewed, CI broken, and even the domain for the docs lapsing once. They have essentially said the project is unmaintained themselves: https://github.com/gnocchixyz/gnocchi/issues/1049 Given that OpenStack telemetry relies on it, we needed to decide what to do. We tried talking to the devs which spun it off outside of OpenStack, but they seem disinclined to interact with the OpenStack community, or move the project back to our infra/governance despite OpenStack looking like the only consumers of Gnocchi as a project. We want to find a solution, and the feeling is that they don't. So we've opted to fork it back and now the discussion is how to approach that fork. The OpenStack community doesn't want to maintain a time series database, but our telemetry API is part of it. We are putting it under non-OpenStack namespace to start, but we need to decide what the long term place for it should be. Do we want to make it an official project again? Do we keep it just as an API and drop the time series DB part for another DB? Do we build a new API back into Ceilometer and switch to a different backend like InfluxDB? We don't know yet, and we want some input from people who use the service so we can hopefully work with OpenStack telemetry as a whole and figure out what the long term picture is. If Gnocchi matters to you at all, or you use it, we want to hear from you. Cheers, Adrian Turjak

3 3