December 2018 - openstack-discuss

[nova] When can/should we remove old nova-status upgrade checks?
by Matt Riedemann 20 Dec '18

20 Dec '18

Questions came up in review [1] about dropping an old "nova-status upgrade check" which relies on using the in-tree placement database models for testing the check. The check in question, "Resource Providers", compares the number of compute node resource providers in the nova_api DB against the number of compute nodes in all cells. When the check was originally written in Ocata [2] it was meant to help ease the upgrade where nova-compute needed to be configured to report compute node resource provider inventory to placement so the scheduler could use placement. It looks for things like >0 compute nodes but 0 resource providers indicating the computes aren't reporting into placement like they should be. In Ocata, if that happened, and there were older compute nodes (from Newton), then the scheduler would fallback to not use placement. That fallback code has been removed. Also in Ocata, nova-compute would fail to start if nova.conf wasn't configured for placement [3] but that has also been removed. Now if nova.conf isn't configured for placement, I think we'll just log an exception traceback but not actually fail the service startup, and the node's resources wouldn't be available to the scheduler, so you could get NoValidHost failures during scheduling and need to dig into why a given compute node isn't being used during scheduling. The question is, given this was added in Ocata to ease with the upgrade to require placement, and we're long past that now, is the check still useful? The check still has lots of newton/ocata/pike comments in it, so it's showing its age. However, one could argue it is still useful for base install verification, or for someone doing FFU. If we keep this check, the related tests will need to be re-written to use the placement REST API fixture since the in-tree nova_api db tables will eventually go away because of extracted placement. The bigger question is, what sort of criteria do we have for dropping old checks like this besides when the related code, for which the check was added, is removed? FFU kind of throws a wrench in everything, but at the same time, I believe the prescribed FFU steps are that online data migrations (and upgrade checks) are meant to be run per-release you're fast-forward upgrading through. [1] https://review.openstack.org/#/c/617941/26/nova/tests/unit/cmd/test_status.… [2] https://review.openstack.org/#/c/413250/ [3] https://github.com/openstack/nova/blob/stable/ocata/nova/compute/manager.py… -- Thanks, Matt

5 5

Devstack failure “Oslo.concurrency”
by d.lake＠surrey.ac.uk 20 Dec '18

20 Dec '18

Hello I’m trying to rebuild a Devstack system on an identical machine to a working system from August. Same base OS (Centos 7.5), same simple local.conf. But this system is failing with Oslo.concurrency not at 2.26. This is bizarre because when I update Oslo.concurrency using pip, I’m given 2.29. Yet something in Devstack insists on going back to 2.25.1 despite knowing that I need 2.26. What is most annoying is that I thought that by keeping all the basic build identical I would save myself the pain that is OpenStack installation. How do I work around this please? If I clear out /usr/lib/python2.7/site-packages, this doesn’t seem to help at all. Thanks David Sent from my iPhone

3 3

[tripleo][openstack-ansible] collaboration on os_tempest role update IV - Dec 19, 2018
by Chandan kumar 19 Dec '18

19 Dec '18

Hello, As 2018 is about to end, Here is the last updates on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: [1.] Create basic doc structure - https://review.openstack.org/623512 [2.] Added support for installing tempestconf from distro - https://review.openstack.org/622999 [3.] Revert "Use tempest run for generating subunit results" - https://review.openstack.org/625070 Revert reason: when --subunit flag is used with tempest run, either the tests passes or fails, It was always returning success. We are investigating and working on the same to fix it. python-tempestconf: [4.] Handle Forbidden exception when creating role - https://review.openstack.org/#/c/624411/ [5.] Adapt python-tempestconf to python3 - https://review.openstack.org/#/c/622343/ [6.] Add argument which allows users to add extensions - https://review.openstack.org/620379 Works still in progress: os_tempest: [1.] Better tempest black and whitelist management - https://review.openstack.org/621605 [2.] Update all plugin urls to use https rather than git - https://review.openstack.org/625670 [3.] Remove octavia in favor of octavia-tempest-plugin - https://review.openstack.org/625828 [4.] Use tempest_tempestconf_profile for handling named args - https://review.openstack.org/623187 [5.] Add tempestconf_git_url var for tempestconf testing - https://review.openstack.org/626092 [6.] Added support for installing python-tempestconf from git - https://review.openstack.org/625904 python-tempestconf: [7.] Add profile argument - https://review.openstack.org/621567 Summary: While working on adding support of python-tempestconf profile feature support in os_tempest, we found that we cannot test tempestconf patches with os_tempest as tempestconf is getting installed by pip, that's why we were working on adding support for the same to install it from git. Thanks to evrardjp, odyssey4me, jrosser, arxcruz, mnaser, kopecmartin for helping us on our silly queries. Upcoming two weeks: * Complete existing work in progress patches. Note: We are sending next update on 09th Jan, 2019 as Holidays started. Here is the third update [2] Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000831… Thanks, Chandan Kumar

2 1

[requirements] adding pre-commit to requirements blacklist (skip check)
by Sorin Sbarnea 19 Dec '18

19 Dec '18

It seems that the list of linters from the the blacklist.txt file is a bit outdated and missing things like: pre-commit bashate ansilbe-lint ansible-review I discovered that while trying to enable pre-commit on tripleo-upgrades and discovered that check-requirements jobs was failing. If someone can help me merge that it would be great https://review.openstack.org/#/c/626000/ <https://review.openstack.org/#/c/626000/> My review contains only pre-commit because that was the one I really needed but looking at the file it seems it may be useful to add all known https://github.com/openstack/requirements/blob/master/blacklist.txt <https://github.com/openstack/requirements/blob/master/blacklist.txt> Thanks Sorin

1 0

[dev][ops][monasca] Additional meeting time
by Bedyk, Witold 19 Dec '18

19 Dec '18

Hello everyone, Monasca team has decided to hold additional team meetings on Thursdays, 7am UTC [1]. This way we would like to offer more suitable meeting time for developers and operators from Asia/Australia. We would like to try this new format of `double meetings` for some time and we'll keep it if there is demand. Everyone interested is warmly invited to join. If you have any topics you would like to discuss, please add them to the agenda [2]. The next meetings are planned today 1500 UTC and tomorrow 0700 UTC. See you there Witek [1] http://eavesdrop.openstack.org/#Monasca_Team_Meeting [2] https://etherpad.openstack.org/p/monasca-team-meeting-agenda

1 0

openstack magnum on queens kubectl errors
by Ignazio Cassano 19 Dec '18

19 Dec '18

Hello I've just installe openstack magnum on queens and I deployed a kubernets cluster. Heat stack terminated successfully but running kubectl describe node, at the end it reports: Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 0 (0%) 0 (0%) memory 0 (0%) 0 (0%) ephemeral-storage 0 (0%) 0 (0%) Events: Type Reason Age >From Message ---- ------ ---- ---- ------- Warning FailedNodeAllocatableEnforcement 4s (x71 over 70m) kubelet, kubecerts-pvfagyxq6gf6-minion-0 Failed to update Node Allocatable Limits "": failed to set supported cgroup subsystems for cgroup : Failed to set config for supported subsystems : failed to write 2089619456 to memory.limit_in_bytes: write /rootfs/var/lib/containers/atomic/kubelet.0/rootfs/sys/fs/cgroup/memory/memory.limit_in_bytes: invalid argument Anyone can help me ? I read some patches has been applyed on queens for this issue: https://bugs.launchpad.net/magnum/+bug/1763405 but , anycase, I am facing the issue. Regards Ignazio

1 0

[scientific-sig] IRC meeting today, 1100UTC: 2018 retrospective, 2019 conferences, etc
by Stig Telfer 19 Dec '18

19 Dec '18

Hi All - We have an IRC meeting today in #openstack-meeting at 1100UTC - about 90 minutes time. Everyone is welcome. The agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_December_19th_20… Today we’d like to cover the activities of the SIG in 2018, and what we would like to do in 2019. I thought it would also be useful to gather together CFPs and announcements for relevant conferences for the year to come. Cheers, Stig

1 0

Watcher team meeting
by Чадин Александр Сергеев ич 19 Dec '18

19 Dec '18

Watcher team, I propose to shift today’s meeting from 08:00 UTC to 08:45 UTC. Alex

1 0

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 19 Dec '18

19 Dec '18

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[octavia][lbaas] Octavia v1 API will be retired along with neutron-lbaas in 2019.
by Michael Johnson 19 Dec '18

19 Dec '18

Hi Octavia folks, I wanted to send a reminder e-mail out that we are planning to retire both neutron-lbaas and the Octavia v1 API in September 2019 or the OpenStack "U" release, whichever comes first. The Octavia v1 API was used by the neutron-lbaas Octavia provider driver and was not an end-user API. The Octavia v1 API is a proprietary API and is not compatible with the LBaaS v2 API specification or any other LBaaS API specification. If you have questions about this deprecation cycle please see the FAQ wiki: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation If you have questions or concerns not covered by the FAQ, please reach out to the Octavia team either by using the "[octavia]" subject prefix on this mailing list or in our IRC channel #openstack-lbaas. Have a great rest of 2018 and we look forward to working with you in the new year! Michael

1 0