September 2019 - openstack-discuss

[nova][glance][entropy][database] update glance metadata for nova instance
by Jordan Ansell 11 Sep '19

11 Sep '19

Hi Openstack Discuss, I have an issue with nova not synchronizing changes between a glance image and it's local image meta information in nova. I have updated a glance image with the property "hw_rng_model=virtio", and that successfully passes that to new instances created using the updated image. However existing instances do not receive this new property. I have located the image metadata within the nova database, in the **instance_system_metadata** table, and can see it's not updated for the existing instances, and only adding the relevant rows for instances that are created when that property is present. The key being "image_hw_rng_model" and "virtio" being the value. Is there a way to tell nova to update the table for existing instances, and synchronizing the two databases? Or is this the kind of thing that would need to be done *shudder* manually...? If so, are there any experts out there who can point me to some documentation on doing this correctly before I go butcher a couple of dummy nova database? Regards, Jordan

3 4

[Watcher] team meeting at 08:00 UTC today
by li.canwei2＠zte.com.cn 10 Sep '19

10 Sep '19

Hi team, Watcher team will have a meeting at 08:00 UTC today in the #openstack-meeting-alt channel. The agenda is available on https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add any additional items. Thanks! Canwei Li

1 0

[nova][keystone][neutron][kuryr][requirements] breaking tests with new library versions
by Matthew Thode 10 Sep '19

10 Sep '19

NOVA: lxml===4.4.1 nova tests fail https://bugs.launchpad.net/nova/+bug/1838666 websockify===0.9.0 tempest test failing KEYSTONE: oauthlib===3.1.0 keystone https://bugs.launchpad.net/keystone/+bug/1839393 NEUTRON: tenacity===5.1.1 https://2c976b5e9e9a7bed9985-82d79a041e998664bd1d0bc4b6e78332.ssl.cf2.rackc… this could be caused by pytest===5.1.0 as well KURYR: kubernetes===10.0.1 openshift PINS this, only kuryr-tempest-plugin deps on it https://review.opendev.org/665352 MISC: tornado===5.1.1 salt is cauing this, no eta on fix (same as the last year) stestr===2.5.0 needs merged https://github.com/mtreinish/stestr/pull/265 jsonschema===3.0.2 see https://review.opendev.org/649789 I'm trying to get this in place as we are getting closer to the requirements freeze (sept 9th-13th). Any help clearing up these bugs would be appreciated. -- Matthew Thode

7 18

[tc] monthly meeting summary
by Mohammed Naser 10 Sep '19

10 Sep '19

Hi everyone, The TC held it’s monthly meeting on the 5th of September 2019 and this email provides a summary of that meeting. We contacted Alan to mention that TC will have some presence at the Shanghai leadership meeting alongside other OSF projects on November 3rd, so the day before the summit. Rico is currently working on an etherpad to update SIG guidelines to simplify the process for new SIGs. Once the draft version is done, they will ask SIG chairs to join in the editing part. We still have to contact interested parties for a new ‘large scale’ SIG so we will follow up again on that action item in the next meeting. Graham is currently in the process of testing the code in order to make the proposal bot for propose project-template patches for specific releases. We’re working on adding some forum sessions ideas for the TC and we’ve got volunteers in the forum selection committee. Thierry finished making goal selection a two-step process and it's been merged. There are a few projects that lacked a PTL elected, we’ve discussed the following points for each: - Cyborg: Sundar self-nominated but only on the mailing list, therefore we will appoint them. - Designate: The developers who have expressed interest didn’t have commits, so Graham will sync with both of them to see how if can make it work. - OpenstackSDK: Monty might have missed the notice since they were traveling so Thierry will reach out to him to see if they want to take it again or has suggestions. - I18n: Ian Y. Choi expressed interest but couldn’t run because they were an election official. - {PowerVM,Win}stackers: The code and review activity was quiet and they missed election twice in a row so we proposed to remove them from project teams list and if they want to continue they can as a SIG. - Placement: we are trying to find someone to volunteer by reaching out to Placement and Nova team. We started discussing a change in the process for release names and the rest of that discussion carried over into office hours. I hope that I covered most of what we discussed, for the full meeting logs, you can find them here: http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-09-05-14.00.log.html Thanks! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

Invite Oleg Ovcharuk to join the Mistral Core Team
by András Kövi 10 Sep '19

10 Sep '19

I would like to invite Oleg Ovcharuk <vgvoleg(a)gmail.com> to join the Mistral Core Team. Oleg has been a very active and enthusiastic contributor to the project. He has definitely earned his way into our community. Thank you, Andras

4 4

[tc] weekly update
by Mohammed Naser 10 Sep '19

10 Sep '19

Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # New Projects - os_murano (under openstack-ansible) # General Changes - We made a few improvements while reviewing the separation of goal definition from goal selection: https://review.opendev.org/#/c/677938/ Thanks! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[charms] Retiring charm-neutron-api-genericswitch
by Corey Bryant 10 Sep '19

10 Sep '19

Hi All, I'm going to retire charm-neutron-api-genericswitch today as it is currently not maintained. I've already discussed and received approval to do so from the original author and the current charms PTL, so this serves as a more broad announcement. Thanks, Corey

1 0

[Horizon] Help making custom theme
by Amy Marrich 10 Sep '19

10 Sep '19

For the Grace Hopper Conference's Open Source Day we're doing a Horizon based workshop for OpenStack (running Devstack Pike). The end goal is to have the attendee teams create their own OpenStack theme supporting a humanitarian effort of their choice in a few hours. I've tried modifying the material theme thinking it would be the easiest route to go but that might not be the best way to go about this.:) I've been getting some assistance from e0ne in the Horizon channel and my logo now shows up on the login page, and I had already gotten the SITE_BRAND attributes and the theme itself to show up after changing the local_settings.py. If anyone has some tips or a tutorial somewhere it would be greatly appreciated and I will gladly put together a tutorial for the repo when done. Thanks! Amy (spotz)

3 6

[release][cyborg] os-acc status
by Thierry Carrez 10 Sep '19

10 Sep '19

Hi Cyborgs, One of your deliverables is the os-acc library. It has seen no change over this development cycle and therefore was not released at all in train. We have several options for this library now: 1- It's still very much alive and desired and just has exceptionally not seen much activity during this cycle. We should just cut a stable/train branch from the last release available (0.2.0) and continue in ussuri. 2- It's a valuable library, it just changes extremely rarely. We should make it independent from the release cycle and have it release at its own rhythm. 3- Development has stopped on this, and the library is not useful right now. We should retire this deliverable so that we do not build wrong expectations for our users. Please let us know which option fits the current status of os-acc. -- Thierry Carrez (ttx)

3 4

[placement][ptl][tc] Call for Placement PTL position
by Ghanshyam Mann 10 Sep '19

10 Sep '19

Hello Everyone, With Ussuri Cycle PTL election completed, we left with Placement project as leaderless[1]. In today TC meeting[2], we discussed the few possibilities and decided to reach out to the eligible candidates to serve the PTL position. We would like to know if anyone from Placement core team, Nova core team or PTL (as placement main consumer) of any other interested/related developer is interested to take the PTL position? [1] https://governance.openstack.org/election/results/ussuri/ptl.html [2] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-09-05-14.00.log.htm… -TC (gmann)

5 8

OSA upgrading Xenial Queens to Bionic Rocky
by Grant Morley 10 Sep '19

10 Sep '19

Hi all, I was wondering if there was a guide for upgrading OpenStack Ansible from Ubuntu 16.04 Queens to Ubuntu 18.04 Rocky? I remember a long time ago there was an etherpad set up for upgrading from 14.04 -> 16.04 but I can't seem to find anything similar for going to 18.04. Annoyingly as we don't have lots of hardware, we are going to have to upgrade in place. If there are any guides that would be much appreciated. Many thanks. -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

2 1

[neutron][vmware][vsphere] integration
by Ionut Biru 10 Sep '19

10 Sep '19

Hello guys, I'm trying to integrate openstack stein with an already running vmware vsphere cluster. All the documentation that I found explain how do it with distributed switches or port groups but currently in my setup, vmware is using Standard Network. Openstack Stein was deployed using OSA , neutron was configured using ovs and i configured the integrated_bridge to br-int. I tried first to deployed using linux-bridge but when I tried to deployed an instance, neutron returned that only ovs or dvs method is supported. Now when ovs when I'm deploying an instance with network, nova returns an error message: 2019-09-10 10:15:19.010 22443 ERROR nova.compute.manager [instance: d8d1cbb8-5c1c-4b98-9739-bea0668cfaa5] VimFaultException: An error occurred during host configuration. 2019-09-10 10:15:19.010 22443 ERROR nova.compute.manager [instance: d8d1cbb8-5c1c-4b98-9739-bea0668cfaa5] Faults: ['PlatformConfigFault'] How do you guys integrate neutron with vmware vsphere with standard network? Is there a driver that I need to use? -- Ionut Biru - https://fleio.com

1 0

Thank you Stackers for five amazing years!
by Chris Hoge 10 Sep '19

10 Sep '19

Hi everyone, After more than nine years working in cloud computing and on OpenStack, I've decided that it is time for a change and will be moving on from the OpenStack Foundation. For the last five years I've had the honor of helping to support this vibrant community, and I'm going to deeply miss being a part of it. OpenStack has been a central part of my life for so long that it's hard to imagine a work life without it. I'm proud to have helped in some small way to create a lasting project and community that has, and will continue to, transform how infrastructure is managed. September 12 will officially be my last day with the OpenStack Foundation. As I make the move away from my responsibilities, I'll be working with community members to help ensure continuity of my efforts. Thank you to everyone for building such an incredible community filled with talented, smart, funny, and kind people. You've built something special here, and we're all better for it. I'll still be involved with open source. If you ever want to get in touch, be it with questions about work I've been involved with or to talk about some exciting new tech or to just catch up over a tasty meal, I'm just a message away in all the usual places. Sincerely, Chris chris(a)hogepodge.com Twitter/IRC/everywhere else: @hogepodge

10 9

[keystone] cannot use 'openstack trust list' without admin role
by Francois Scheurer 10 Sep '19

10 Sep '19

Dear Keystone Experts, I have an issue with the openstack client in stage (using Rocky), using a user 'fsc' without 'admin' role and with password auth. 'openstack trust create/show' works. 'openstack trust list' is denied. But keystone policy.json says: "identity:create_trust": "user_id:%(trust.trustor_user_id)s", "identity:list_trusts": "", "identity:list_roles_for_trust": "", "identity:get_role_for_trust": "", "identity:delete_trust": "", "identity:get_trust": "", So "openstack list trusts" is always allowed. In keystone log (I replaced the uid's by names in the ouput below) I see that 'identity:list_trusts()' was actually granted but just after that a_*admin_required()*_ is getting checked and fails... I wonder why... There is also a flag*is_admin_project=True* in the rbac creds for some reason... Any clue? Many thanks in advance! Cheers Francois #openstack --os-cloud stage-fsc trust create --project fscproject --role creator fsc fsc #=> fail because of the names and policy rules, but using uid's it works openstack --os-cloud stage-fsc trust create --project aeac4b07d8b144178c43c65f29fa9dac --role 085180eeaf354426b01908cca8e82792 3e9b1a4fe95048a3b98fb5abebd44f6c 3e9b1a4fe95048a3b98fb5abebd44f6c +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+ openstack --os-cloud stage-fsc trust show e74bcdf125e049c69c2e0ab1b182df5b +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+ #this fails: openstack --os-cloud stage-fsc trust list *You are not authorized to perform the requested action: admin_required. (HTTP 403)*

3 3

[ironic] Ironic tempest jobs hitting retry_limit failures
by Clark Boylan 09 Sep '19

09 Sep '19

Hello Ironic, We've noticed that your tempest jobs have been hitting retry_limit failure recently. What this means is we attempted to run the job 3 times but each time the job failed due to "network" problems and Zuul eventually gave up. On further investigation I found that this is happening because the ironic tempest jobs are filling the root disk on rackspace nodes (which have a smaller root / + ephemeral drive mounted at /opt) with libvirt qcow2 images. This seems to cause ansible to fail to operate because it needs to write to /tmp and it thinks there is a "network" error. I've thrown my investigation into a bug for you [0]. It would be great if you could take a look at this as we are effectively spinning our wheels for about 9 hours every time this happens. I did hold the node I used to investigate. If you'd like to dig in yourselves just ask the infra team for access to nodepool node ubuntu-bionic-rax-ord-0011007873. Finally, to help debug these issues in the future I've started adding a cleanup-run playbook [1] which should give us network and disk info (can be expanded if necessary too) for every job when it is done running. Even if the disk is full. [0] https://storyboard.openstack.org/#!/story/2006520 [1] https://review.opendev.org/#/c/681100/ Clark

1 0

[devstack][qa][python3] "also install the Python 2 dev library" - still needed?
by Peter Penchev 09 Sep '19

09 Sep '19

Hi, When devstack's `setup_dev_lib` function is invoked and USE_PYTHON3 has been specified, this function tries to also install the development library for Python 2.x, I guess just in case some package has not declared proper Python 3 support or something. It then proceeds to install the Python 3 version of the library and all its dependencies. Unfortunately there is a problem with that, and specifically with script files installed in the system's executable files directory, e.g. /usr/local/bin. The problem appears when some Python library has already been installed for Python 3 (and has installed its script files), but is now installed for Python 2 (overwriting the script files) and is then not forcefully reinstalled for Python 3, since it is already present. Thus, the script files are last modified by the Python 2 library installation and they have a hashbang line saying `python2.x` - so if something then tries to execute them, they will run and use modules and libraries for Python 2 only. We experienced this problem when running the cinderlib tests from Cinder's `playbooks/cinderlib-run.yaml` file - it finds a unit2 executable (installed by the unittest2 library) and runs it, hoping that unit2 will be able to discover and collect the cinderlib tests and load the cinderlib modules. However, since unittest2 has last been installed as a Python 2 library, unit2 runs with Python 2 and fails to locate the cinderlib modules. (Yes, we know that there are other ways to run the cinderlib tests; this message is about the problem exposed by this way of running them) The obvious solution would be to instruct the Python 2 pip to not install script (or other shared) files at all; unfortunately, https://github.com/pypa/pip/issues/3980 ("Option to exclude scripts on install"), detailing a very similar use case ("need it installed for Python 2, but want to use it with Python 3") has been open for almost exactly three years now with no progress. I wonder if I could try to help, but even if this issue is resolved, there will be some time before OpenStack can actually depend on a recent enough version of pip. A horrible workaround would be to find the binary directory before installing the Python 2 library (using something like `pip3.7 show somepackage` and then running some heuristics on the "Location" field), tar'ing it up and then restoring it... but I don't know if I even want to think about this. Another possible way forward would be to consider whether we still want the Python 2 libraries installed - is OpenStack's Python 3 transition reached a far enough stage to assume that any projects that still require Python 2 *and* fail to declare their Python 2 dependencies properly are buggy? To be honest, this seems the most reasonable path for me - drop the "also install the Python 2 libs" code and see what happens. I could try to make this change in a couple of test runs in our third-party Cinder CI system and see if something breaks. Here is a breakdown of what happens, with links to the log of the StorPool third-party CI system for Cinder: https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `stack.sh` invokes `pip_install` for `os-testr` https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip_install` sees that we want a Python 3 installation and invokes `pip3.7` to install os-testr. https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip3.7` wants to install `unittest2` https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip3.7` has installed `unittest2` - now `/usr/local/bin/unit2` has a hashbang line saying `python3.7` Now this is where it gets, uhm, interesting: https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `setup_dev_lib` is invoked for `os-brick` https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `setup_dev_lib`, seeing that we really want a Python 3 installation, decides to install `os-brick` for Python 2 just in case. https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip2.7` is invoked to install `os-brick` and its dependencies. https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip2.7` decides it wants to install `unittest2`, too. https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip2.7` has installed `unittest2`, and now `/usr/local/bin/unit2` has a hasbang line saying `python2.7` https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `setup_dev_lib` turns the Python 3 flag back on. https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip3.7` is invoked to install `os-brick` https://spfactory.storpool.com/logs/80/639180/35/check/cinder-storpool-temp… `pip3.7` decides (correctly) that it has already installed `unittest2`, so (only partially correctly) it does not need to install it again. Thus `/usr/local/bin/unit2` is left with a hashbang line saying `python2.7`. Thanks for reading this far, I guess :) G'luck, Peter

4 5

Bug Deputy September 2 - September 9
by Nate Johnston 09 Sep '19

09 Sep '19

Neutrinos, Here is the bug deputy report for this past week. It was an exciting week of CI problems; thanks to everyone who pitched in to get us past those thorny issues. I would call out specifically the two bugs rated as High that have no assignee yet; they are both gate related - one for Neutron, and the other affecting the Patrole project. There is also one bug left Untriaged because I was unable to validate the bug; I would appreciate a triaging look if you can. Thanks! Nate ---- Critical - https://bugs.launchpad.net/bugs/1842482 "test_get_devices_info_veth_different_namespaces" fails because veth1_1 interface has a link device in the same namespace Status: Fix Committed (slaweq) https://review.opendev.org/680001 - https://bugs.launchpad.net/bugs/1842517 neutron-sanity-check command fails if netdev datapath is used Status: In Progress (deepak.tiwari) No change registered in LP bug - https://bugs.launchpad.net/bugs/1842657 Job networking-ovn-tempest-dsvm-ovs-release is failing 100% times Status: Fix Committed (maciej.josefczyk) https://review.opendev.org/661065 - https://bugs.launchpad.net/bugs/1842659 Funtional tests of start and restart services failing 100% times Status: Fix Committed (slaweq) https://review.opendev.org/680001 High - https://bugs.launchpad.net/bugs/1843285 Trunk scenario test test_subport_connectivity failing with iptables_hybrid fw driver Status: Unassigned - https://bugs.launchpad.net/bugs/1842666 Bulk port creation with supplied security group also adds default security group Status: In Progress (njohnston) https://review.opendev.org/679852 - https://bugs.launchpad.net/bugs/1843025 FWaaS v2 fails to add ICMPv6 rules via horizon Status: In Progress (haleyb) https://review.opendev.org/680753 - https://bugs.launchpad.net/bugs/1843282 Rally CI not working since jsonschema version bump Status: Fix Committed (ralonsoh) https://review.opendev.org/681001 - https://bugs.launchpad.net/bugs/1843290 Remove network flavor profile fails Status: Unassigned Note: Currently breaking the gate for the Patrole project Medium - https://bugs.launchpad.net/bugs/1842327 Report in logs when FIP associate and disassociate Status: In progress (ralonsoh) https://review.opendev.org/680976 Low - https://bugs.launchpad.net/bugs/1842934 multicast scenario test failing when guest image don't have python3 installed Status: In Progress (slaweq) https://review.opendev.org/680428 - https://bugs.launchpad.net/bugs/1842937 Some ports assigned to routers don't have the correspondent routerport register Status: In Progress (ralonsoh) No change registered in LP bug - https://bugs.launchpad.net/bugs/1843269 Nova notifier called even if set to False Status: In Progress (haleyb) https://review.opendev.org/681016 RFE - https://bugs.launchpad.net/bugs/1843218 allow to create record on default zone from tenants Untriaged - https://bugs.launchpad.net/bugs/1843211 network-ip-availabilities' result is not correct when the subnet has no allocation-pool Status: Unassigned

1 1

[edge] Edge whitepaper and tutorial authors needed
by Ildiko Vancsa 09 Sep '19

09 Sep '19

Hi, I’m reaching out to point you to two mail threads on the edge-computing mailing list. The edge working group is looking into writing up a second whitepaper with a few detailed use cases and information about the reference architecture work the group has been doing. If you are interested in this work please __reach out to me or check out this mail thread__: http://lists.openstack.org/pipermail/edge-computing/2019-September/000632.h… The other work item is writing up edge tutorials about frameworks to a German magazine. __This is a short deadline activity, please reach out to me if you are interested in participating.__ For further information please see this mail thread: http://lists.openstack.org/pipermail/edge-computing/2019-September/000633.h… Please let me know if you have questions to any of the above. Thanks, Ildikó

1 0

[nova] Offline Installation of Openstack
by Premdeep S 09 Sep '19

09 Sep '19

Hi Team, Requesting your help on below. We have a requirement to setup Openstack in an isolated infra. We will not be provided with Internet. How can we set it up? 1. Can we have a local repository (Rocky, Universal, etc)created? If so how do we manage it? 2. We have noticed lot of package dependencies while setting up Openstack Infra, so will creating a local repository help in an implementation when we do not have an internet. What is the success rate? Thanks Prem

2 2

[manila][ops] Shanghai Forum - Manila Topic Planning
by Tom Barron 09 Sep '19

09 Sep '19

As mentioned several times in the Manila Community Meeting, we have posted an etherpad to brainstorm and gauge interest in topics for the Forum at the upcoming OpenInfra Summit in Shanghai. The point of the Forum sesssions is to get feedback from operators and users on things that need fixing, improvements and enhancements, and more generally about the strategic direction for Manila. So please take a look and update this etherpad with topic ideas and indicate your interest in topics already present if you have an interest in Manila. It doesn't matter whether you contribute to the project or not, or whether you will yourself be attending the Forum: https://etherpad.openstack.org/p/manila-shanghai-forum-brainstorming We will review this etherpad in our community meeting at 1500 UTC on 19 September in #openstack-meeting-alt on Freenode, one day before the Forum proposal deadline. Please feel free to join that meeting to discuss, and in any case please add to the brainstorming deadline before then. Cheers, -- Tom Barron

1 0

[keystone] Pre-feature-freeze update
by Colleen Murphy 09 Sep '19

09 Sep '19

I won't be writing a team report since I'm still figuring out which way is up after a week in the desert, but with feature freeze next week I wanted to give a status update on all the in-flight work that is due next week: * System Scope and Default Roles All documented scope[1] and role[2] migrations are in progress. Some are closer to done than others. Since enforce_scope cannot be set to true in keystone.conf until all of them are completed, and since leaving deprecation warnings in the logs for more than two cycles is a very undesirable operator experience, it's essential we complete these by next week. * Application Credential Access Rules This implementation[3] for keystone has been completed for months but the last few patches in the stack are lacking reviews. Client support has been proposed but with the final client release happening next week we will likely not land it until next cycle. * Resource Options and Immutable Resources Resource options[4] and immutable resources[5] are intertwined and the finishing touches are still being applied. Hope to have this completed early next week. * Federated Attributes for Users Support for federated attributes for users[6] is passing CI but needs reviews, it's unclear to me how much has changed since those patches were originally proposed two years ago so it's unfortunate that we're only left with a week to look at them. * Expiring Group Membership There is only a partial implementation proposed for expiring group membership[7] and neither patch is passing CI. This seems to have effectively missed the feature proposal freeze deadline which was a few weeks ago and will not likely make it in this cycle. * CI After skimming the meeting logs I saw the unit test timeout problem was discussed and a temporary workaround was proposed[8]. This sounded like a great idea but it seems that no one implemented it, so I did[9]. Unfortunately this will conflict with all the system-scope/default-roles patches in flight. With how many changes need to go in and how slow it will be with all of them needing to be rechecked and continually making the problem even worse, I propose we go ahead and merge the workaround ASAP and update all the in-flight changes to move the protection tests to the new location. It also appears that the non-voting federation CI broke recently, this will hopefully be fixed by updating the opensuse nodeset[10]. [1] https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope [2] https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles [3] https://review.opendev.org/#/q/topic:bp/whitelist-extension-for-app-creds [4] https://review.opendev.org/678322 [5] https://review.opendev.org/#/q/topic:immutable-resources [6] https://review.opendev.org/#/q/topic:bp/support-federated-attr [7] https://review.opendev.org/#/q/topic:bug/1809116 [8] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-08-27-1… [9]https://review.opendev.org/680788 [10] https://review.opendev.org/680799 Colleen

2 2

[nova][telemetry] does Telemetry still use the Nova server usage audit log API?
by melanie witt 09 Sep '19

09 Sep '19

Howdy all, TL;DR: I have a question, does the Telemetry service (or any other service) still make use of the server usage audit log API in Nova [1]? Recently I was investigating customer issues where the nova.task_log database table grows infinitely and is never cleaned up [2]. I asked about it today in #openstack-nova [3] and Matt Riedemann explained that the API is toggled via config option [4] and that the Telemetry service is/was the consumer of the API. I found through code inspection that there are no methods for deleting nova.task_log records and am trying to determine what is the best way forward for handling cleanup. Matt mentioned the possibility of deprecating the server usage audit log API altogether, which we might be able to do if no one is using it anymore. So, I was thinking: * If Telemetry is no longer using the server usage audit log API, we deprecate it in Nova and notify deployment tools to stop setting [DEFAULT]/instance_usage_audit = true to prevent further creation of nova.task_log records and recommend manual cleanup by users or * If Telemetry is still using the server usage audit log API, we create a new 'nova-manage db purge_task_log --before <date>' (or similar) command that will hard delete nova.task_log records before a specified date or all if --before is not specified Can anyone shed any light on whether Telemetry, or any other service, still uses the server usage audit log API in Nova? Would we be able to deprecate it? If we can't, what do you think of the nova-manage command idea? I would appreciate hearing your thoughts about it. Cheers, -melanie [1] https://docs.openstack.org/api-ref/compute/#server-usage-audit-log-os-insta… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1726256 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [4] https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.in…

4 5

[nova][neutron][all][openstack-devs] studying and analysing Openstack developers
by Farida El Zanaty 09 Sep '19

09 Sep '19

Hi! I am Farida El-Zanaty from McGill University. Under the supervision of Prof. Shane McIntosh, my research aims to study design discussions that occur between developers during code reviews. Last year, we published a study about the frequency and types of such discussions that occur in OpenStack Nova and Neutron (http://rebels.ece.mcgill.ca/papers/esem2018_elzanaty.pdf). We are reaching out to OpenStack developers to better understand their perspectives on design discussions during code reviews. Those who are interested can start by participating in our 10-minute survey about their experiences as both the code reviewer and author. Survey participants will be entered into a raffle for a $50 Amazon gift card. Survey: https://forms.gle/Hhn191f6cxF5hVgG8 Thanks for your time, Farida El-Zanaty

1 0

Re: [devstack][qa][python3] "also install the Python 2 dev library" - still needed?
by Peter Penchev 09 Sep '19

09 Sep '19

On Mon, Sep 9, 2019 at 5:40 PM Peter Penchev <pp(a)storpool.com> wrote: > On Mon, Sep 9, 2019 at 2:55 PM Sean Mooney <smooney(a)redhat.com> wrote: > >> On Mon, 2019-09-09 at 11:22 +0300, Peter Penchev wrote: >> > Hi, >> > >> > When devstack's `setup_dev_lib` function is invoked and USE_PYTHON3 has >> > been specified, this function tries to also install the development >> library >> > for Python 2.x, I guess just in case some package has not declared >> proper >> > Python 3 support or something. It then proceeds to install the Python 3 >> > version of the library and all its dependencies. >> > >> > Unfortunately there is a problem with that, and specifically with script >> > files installed in the system's executable files directory, e.g. >> > /usr/local/bin. The problem appears when some Python library has already >> > been installed for Python 3 (and has installed its script files), but is >> > now installed for Python 2 (overwriting the script files) and is then >> not >> > forcefully reinstalled for Python 3, since it is already present. Thus, >> the >> > script files are last modified by the Python 2 library installation and >> > they have a hashbang line saying `python2.x` - so if something then >> tries >> > to execute them, they will run and use modules and libraries for Python >> 2 >> > only. >> yes this is a long standing issue. we discovered it a year ago but it was >> never fix. >> >> in Ussrui i guess one of the first changes to devstack to make it python >> 3 only >> will be to chagne that behavior. im not sure if we will be able to change >> it before then. >> >> whenever you us libs_from_git in your local.conf on a python 3 install it >> will install >> them twice both with python 2 and python 3. i hope more distros elect to >> symlink /usr/bin/python to python 3 >> some distros have chosen to do that on systems that are python only and i >> believe that is the correct >> approch. >> >> when i encountered this it was always resuliting on the script header >> being #!/usr/bin/python with no >> version suffix i >> gues on a system where that points to python 3 the python 2.7 install >> might write python2.7 >> there instead? >> > > It depends on what version of pip is invoked; I think that the way > devstack invokes it nowadays it will always provide a version on the > shebang line. > > >> >> > >> > We experienced this problem when running the cinderlib tests from >> Cinder's >> > `playbooks/cinderlib-run.yaml` file - it finds a unit2 executable >> > (installed by the unittest2 library) and runs it, hoping that unit2 >> will be >> > able to discover and collect the cinderlib tests and load the cinderlib >> > modules. However, since unittest2 has last been installed as a Python 2 >> > library, unit2 runs with Python 2 and fails to locate the cinderlib >> > modules. (Yes, we know that there are other ways to run the cinderlib >> > tests; this message is about the problem exposed by this way of running >> > them) >> > >> > The obvious solution would be to instruct the Python 2 pip to not >> install >> > script (or other shared) files at all; unfortunately, >> > https://github.com/pypa/pip/issues/3980 ("Option to exclude scripts on >> > install"), detailing a very similar use case ("need it installed for >> Python >> > 2, but want to use it with Python 3") has been open for almost exactly >> > three years now with no progress. I wonder if I could try to help, but >> even >> > if this issue is resolved, there will be some time before OpenStack can >> > actually depend on a recent enough version of pip. >> well the obvious solution is to stop doing this entirly. >> it was added as a hack to ensure if you use LIB_FROM_GIT in you >> local.conf that those >> libs would always be install from the git checkout that you specified in >> you local.conf >> for train we are technically requireing all project to run under python 3 >> so we could remove >> the fallback mechanium of in stalling under python 2. it was there incase >> a service installed >> under python 2 to ensure it used the same version of the lib and did not >> use a version form >> pypi instead. i wanted to stop doing this last year but we could not >> becase not all project >> could run under python 3. but now that they should be able to we dont >> need this hack anymore. >> we should change it to respec the python version you have selected. that >> will speed >> up stacking speed as we wont have to install everything twice and fix the >> issue you have encountered. >> > > Yeah, thanks for confirming my thoughts that this might be the right > solution. I've proposed https://review.opendev.org/681029/ (and set > workflow -1) to wait for the Ussuri cycle. > > >> > >> > A horrible workaround would be to find the binary directory before >> > installing the Python 2 library (using something like `pip3.7 show >> > somepackage` and then running some heuristics on the "Location" field), >> > tar'ing it up and then restoring it... but I don't know if I even want >> to >> > think about this. >> > >> > Another possible way forward would be to consider whether we still want >> the >> > Python 2 libraries installed - is OpenStack's Python 3 transition >> reached a >> > far enough stage to assume that any projects that still require Python 2 >> > *and* fail to declare their Python 2 dependencies properly are buggy? >> To be >> > honest, this seems the most reasonable path for me - drop the "also >> install >> > the Python 2 libs" code and see what happens. I could try to make this >> > change in a couple of test runs in our third-party Cinder CI system and >> see >> > if something breaks. >> > > G'luck, > Peter > > Argh, I sent this from the wrong account, did I not... G'luck, Peter

1 0

Re: [tc] Campaign Question: Treating the Problem, not just the symptoms- Burnout, No Polling, etc
by Chris Dent 09 Sep '19

09 Sep '19

On Mon, 9 Sep 2019, Adam Spiers wrote: > Chris Dent <cdent+os(a)anticdent.org> wrote: >> On Fri, 6 Sep 2019, Jeremy Stanley wrote: >> >>> I'm disappointed that you don't think the software you're making is >>> open source. I think the software I'm making is open source, and if >>> I didn't I wouldn't be here. > > I wouldn't either. I'd be very worried to live in a world where there > was no serious open source rival to AWS, Azure, GCE etc. (One possible tl;dr of the below is: For at least some people working on OpenStack the more direct and immediate cause and result of their work (whatever their intent) is the enablement of corporate profit (through sales and support) not individual humans using the software.) >From some standpoints I would guess that OpenStack looks and behaves like open source: people work on it collaboratively and the code is available for anyone to change. And I would agree that from that standpoint it is open source, and the four opens are good both in letter and in spirit. I would also agree that the academic and other non-profit use of a OpenStack that Jeremy is very compelling and motivating. But the context of much of this thread has been about the experience of the developers making OpenStack. How they come to be in this situation, how they manage their work, who they work with, what drives decisions, etc. (What follows is a ramble. A apologize for not being able to write less. But you did ask so here it goes.) In the context of daily developer experience, things are less clear. They would be more clear and would feel more like open source if I was more frequently collaborating in the creation of code with people who were using OpenStack. But I don't. Most frequently I'm collaborating with people who instead of using OpenStack are helping to make something for other people (with whom they have infrequent collaborative contact) to use OpenStack. For some people this is not the case. For example, many of the people who have been deeply involved with OpenStack infra use OpenStack all the time and also work hard to improve the code of OpenStack. But on a daily basis that isn't my experience. Nor does it feel like the experience of most of the people I tend to collaborate with. Yes, sometimes I will collaborate with someone from CERN to create a feature, but this is rare. Usually I collaborate with people from Intel, VMware, Red Hat, and a variety of Telco vendors. Doing a thing to help an existing customer or hoped for notional customer, both of whom are abstractions at a distance, not humans. This isn't a bad thing. Organizations collaborating in any way is great. But it doesn't _feel_ like "open source" to me. And that feeling is an important factor (I think) in analyzing the motivations people experience when working on OpenStack and the choices they make with regard to how they act in the environment. As someone who has done what could be called open source since long before the term was invented, the common failure of corporate patrons to give maintainability and quality (of product and (critically) the experience of creating it) sufficient attention is a source of a great deal of resentment and internal conflict. I am far too conscious of the necessity to compensate for that failure if I want to feel a sense of well being with what I'm helping to create (both in terms of product and the environment it is being created in). That is: I care enough to try to do what I think is right. In this thread, and the one that started it, we've put forward the "maybe we should just chill" as a bit of an antidote to burnout and overcommitment. While I rationally think that's the right idea, emotionally it is very hard to do and the source of that difficulty is this: OpenStack has constituted itself over the years as the domain of contributing corporations. Many paid contributors for whom working on OpenStack is their job. At the same time we have also been very vocal about being not just open source, but a source of good wisdom (the four opens) on how to do open source well. The latter creates a community I want to believe in. A source of pride. The former creates a conflict of interest, a frequent inability to do the actually right thing for the long term health of the community. A source of shame. Continued pleas to get the corporates to do "open source" well -- that is with correct attention to: * developer experience * maintainability * architectural integrity * deeper/closer ties to user engagement and their satisfaction and thus some akin to "actually open source" -- have fallen on what, if actions speak louder than words, are deaf ears. This creates a conundrum. I've tried a variety of ways out of it. One I'm experimenting with now is realizing that OpenStack really isn't, now, proper open source. And if it is not, then I don't have to care because they don't. > Again I'd be very interested to learn more about your take on what we > can do better. There are two directions to go: Maintain the mode of corporate-contribution-driven development. If this is to be healthy then the corps doing that contribution need to invest far more heavily in general, but especially in the items I've listed above at "correct attention". This would grant the community sufficient resources to evolve out of its aging models for development and governance. You have to have some free space to have the head space to get to new spaces. Start breaking down the corporate-contribution-driven development. Encourage professional openstack devs (like me) to age out of the system and discourage new ones coming in. Encourage feature development from and via users. Feature velocity might drop drastically but they might be features individuals actually use within a few weeks of their release rather than a few years. Some of this latter is already happening. Especially in what some people call the non-core projects; things associated with deployment for example. But in projects like nova we're heavily driven by trying to create a feature base which is predicted to drive sales, either directly or indirectly. And, though opinions and experiences differ, my opinion and experience is that driving sales as a direct factor is anathema to "open source". Indirect? Sure, whatever, if that floats your boat. The proper direct factor is humans. There's a lot more to this than I've stated here, but I hope that gives at least something in answer to the question. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[ansible-sig] weekly meetings
by Mohammed Naser 09 Sep '19

09 Sep '19

Hi everyone, For those interested in getting involved, the ansible-sig meetings will be held weekly on Fridays at 2:00 pm UTC starting next week (13 September 2019). Looking forward to discussing details and ideas with all of you! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

3 3

[all][ptl][tc][docs] Develope a code-review practices document
by Trinh Nguyen 09 Sep '19

09 Sep '19

Hi all, I find it's hard sometimes to handle situations in code-review, something likes solving conflicts while not upsetting developers, or suggesting a change to a patchset while still encouraging the committer, etc. I know there are already documents that guide us on how to do a code-review [2] and even projects develope their own procedures but I find they're more about technical issues rather than human communication. Currently reading Google's code-review practices [1] give me some inspiration to develop more human-centric code-review guidelines for OpenStack projects. IMO, it could be a great way to help project teams develop stronger relationship as well as encouraging newcomers. When the document is finalized, I then encourage PTLs to refer to that document in the project's docs. Let me know what you think and I will put a patchset after one or two weeks. [1] https://google.github.io/eng-practices/review/ [2] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html [3] https://docs.openstack.org/doc-contrib-guide/docs-review.html [4] https://docs.openstack.org/nova/rocky/contributor/code-review.html [5] https://docs.openstack.org/neutron/pike/contributor/policies/code-reviews.h… Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 1

[winstackers][powervmstackers][tc] removing winstackers and PowerVMStackers from TC governance
by Doug Hellmann 09 Sep '19

09 Sep '19

Following the U cycle election there was no candidate for either the winstackers or powervmstackers team PTL role. This is the second cycle in a row where that problem has occurred for both teams, which indicates that the teams are not active in the community. During the TC meeting today [1] we discussed removing the teams from governance, so I have proposed the patches to do that [2][3]. Doug [1] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-09-05-14.00.log.htm… [2] https://review.opendev.org/680438 remove powervmstackers team [3] https://review.opendev.org/680439 remove winstackers team

5 5

[placement] "now" worklist
by Chris Dent 09 Sep '19

09 Sep '19

As we near the end of a cycle it can be a bit unclear what tasks are relevant or a priority for the placement project. I've made a worklist in storyboard https://storyboard.openstack.org/#!/worklist/754 called "placement now". It gathers stories from the placement group (placement, osc-placement, os-resource-classes, os-traits) that I've tagged with 'pnow' to mean "these are the things we should be concerned with in the near future". This helps to take off the radar anything from the following groups: * Features that will not be considered this cycle. * Anything related to osc-placement (which has already seen its likely last release for this cycle) This leaves placement (the service) bug fixes, and docs. Not yet there is an item for "documenting the new nested provider features", mostly because the story for that has not solidified. Anything that is currently on that list we should finish before the end of the cycle. I hope that having a focused list can help drive that. Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[mistral] Publish field in workflow tasks
by Ali Abdelal 09 Sep '19

09 Sep '19

Hello, Currently, there are two "publish" fields, one in the task(regular "publish")-the scope is branch and not global, and another under "on-success", “on-error” or “on-complete”. In the current behavior, regular "publish" is ignored if there is "publish" under "on-success", “on-error” or “on-complete” [1]. For example:- (a) version: '2.0' wf1: tasks: t1: publish: res_x1: 1 on-success: publish: branch: res_x2: 2 (b) version: '2.0' wf2: tasks: t1: publish: res_x1: 1 "res_x1" won't be published in (a), but it will in (b). We can either:- 1) Invalidate such syntax. 2) Merge the two publishes together and if there are duplicate keys, there are two options:- a) What takes priority is what's in publish under "on-success" or “on-error” or “on-complete. b) Not allow having a duplicate. What is your opinion? And please tell us if you have other suggestions. [1] https://bugs.launchpad.net/mistral/+bug/1791449

2 1

[heat] Resource handling in Heat stacks
by Andreas Florath 08 Sep '19

08 Sep '19

Hello! Can please anybody tell me, if all resources which are created within a Heat stack belong to the stack in the way that all the resources are freed / deleted when the stack is deleted? IMHO all resources which are created during the initial creation or update of a stack, even if they are ephemeral or only internal created, must be deleted when the stack is deleted by OpenStack Heat itself. Correct? My question might see obvious, but I did not find an explicit hint in the documentation stating this. The reason for my question: I have a Heat template which uses two images to create a server (using block_device_mapping_v2). Every time I run an 'openstack stack create' and 'openstack stack delete' cycle one ephemeral volume is left over / gets not deleted. For me this sounds like a problem in OpenStack (Heat). (It looks that this is at least similar to https://review.opendev.org/#/c/341008/ which never made it into master.) Kind regards Andre

3 4

[all][elections][ptl] Combined Project Team Lead and Technical Committee Election Conclusion and Results
by Jeremy Stanley 08 Sep '19

08 Sep '19

Thank you to all candidates who put their name forward for Project Team Lead (PTL) and Technical Committee (TC) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Adrian Turjak * Barbican : Douglas Mendizábal * Blazar : Pierre Riteau * Cinder : Brian Rosmaita * Cloudkitty : Luka Peschke * Congress : Eric Kao * Documentation : Alexandra Settle * Ec2 Api : Andrey Pavlov * Freezer : geng chc * Glance : Abhishek Kekane * Heat : Rico Lin * Horizon : Akihiro Motoki * Infrastructure : Clark Boylan * Ironic : Julia Kreger * Karbor : Pengju Jiao * Keystone : Colleen Murphy * Kolla : Mark Goddard * Kuryr : Michał Dulko * Loci : Pete Birley * Magnum : Feilong Wang * Manila : Goutham Pacha Ravi * Masakari : Sampath Priyankara * Mistral : Renat Akhmerov * Monasca : Witek Bedyk * Murano : Rong Zhu * Neutron : Sławek Kapłoński * Nova : Eric Fried * Octavia : Adam Harwell * OpenStack Charms : Frode Nordahl * Openstack Chef : Jens Harbott * OpenStack Helm : Pete Birley * OpenStackAnsible : Mohammed Naser * OpenStackClient : Dean Troyer * Oslo : Ben Nemec * Packaging Rpm : Javier Peña * Puppet OpenStack : Shengping Zhong * Qinling : Lingxian Kong * Quality Assurance : Ghanshyam Mann * Rally : Andrey Kurilin * Release Management : Sean McGinnis * Requirements : Matthew Thode * Sahara : Jeremy Freudberg * Searchlight : Trinh Nguyen * Senlin : XueFeng Liu * Solum : Rong Zhu * Storlets : Kota Tsuyuzaki * Swift : Tim Burke * Tacker : dharmendra kushwaha * Telemetry : Rong Zhu * Tricircle : chi zhang * Tripleo : Wes Hayutin * Trove : Lingxian Kong * Vitrage : Eyal Bar-Ilan * Watcher : canwei li * Zaqar : wang hao * Zun : Feng Shengqin Also please join me in congratulating the 6 newly elected members of the TC: Ghanshyam Mann (gmann) Jean-Philippe Evrard (evrardjp) Jay Bryant (jungleboyj) Kevin Carter (cloudnull) Kendall Nelson (diablo_rojo) Nate Johnston (njohnston) Full results: because there were only as many TC candidates as open seats, no poll was held and all candidates were acclaimed Elections: Election process details and results are also available here: https://governance.openstack.org/election/ -- Jeremy Stanley, on behalf of the OpenStack Technical Election Officials

15 24

[tc][neutron] Supported Linux distributions and their kernel
by Adrian Chiris 08 Sep '19

08 Sep '19

Greetings, I was wondering what is the guideline in regards to which kernels are supported by OpenStack in the various Linux distributions. Looking at [1], Taking for example latest CentOS major (7): Every "minor" version is released with a different kernel version, the oldest being released in 2014 (CentOS 7.0, kernel 3.10.0-123) and the newest released in 2018 (CentOS 7.6, kernel 3.10.0-957) While I understand that OpenStack projects are expected to support all CentOS 7.x releases. Does the same applies for the kernels they originally came out with? The reason I'm asking, is because I was working on doing some cleanup in neutron [2] for a workaround introduced because of an old kernel bug, It is unclear to me if it is safe to introduce this change. [1] https://governance.openstack.org/tc/reference/project-testing-interface.htm… [2] https://review.opendev.org/#/c/677095/ Thanks, Adrian.

5 6

Need help trigger aodh alarm
by Anmar Salih 07 Sep '19

07 Sep '19

Hey all, I need help trigger aodh alarm to execute a simple function. I am following the instructions here <https://docs.openstack.org/qinling/rocky/user/aodh.html> but it does't work. Here are my system configurations: 1- Operating system (Ubuntu16 server) -> running on virtual machine 2- Devstack local.conf <https://paste.api-zulu.com/pebexowulo.makefile> file. 3- Devstack Stein release. Note: I tried to install Devstack on Ubuntu16 desktop and Ubuntu18 desktop but no luck. This link <https://imgur.com/a/hThei05> is the error output screen I received during the installation on Ubuntu18 desktop. Thank you in advance. Best Regards.

3 8

[infra][neutron] Requesting help to remove feature branches
by Miguel Lavalle 07 Sep '19

07 Sep '19

Dear Infra Team, We have decided to remove from the Neutron repo the following feature branches: feature/graphql feature/lbaasv2 feature/pecan feature/qos We don't need to preserve any state from these branches. In the case of the first one, no code was merged. The work in the other three branches is already merged into master. Best regards Miguel

3 5

[Octavia]-Seeking some high points on using Octavia
by Singh, Prabhjit 07 Sep '19

07 Sep '19

Hi Michael, I have been trying to get Octavia LbaaS up and running and get performance tested. It has taken me some time to get quite a few things working. While I continue to invest time in using Octavia and stay excited on some of the upcoming features. I have been asked the following questions by my leadership to which I do not have any direct answers. 1. What is the adoption of Octavia, are major organizations looking to adopt and invest in it. Can you provide some numbers 2. Roadmap wise is the Open community committed to investing in Octavia and why 3. Per your suggestion I tried to look up who are the primary companies using Octavia and haven't found a clear indication, any insight would be great. 4. Would features from haproxy 2.0 be included in Octavia 5. There are some open solutions from haproxy, Envoy, consul. How would Octavia compare. 6. Lastly, do you have enough encouragement to keep the project going, I guess I am looking for some motivation for continuing to choose to use Octavia when there are several turnkey solutions ( though offered at a price ). Currently I have been working with Redhat to answer the following questions, these are not for the community, hopefully Redhat will be able to pursue with your team. 1. How to offload logs to an external log/metrics collector 2. How to turn off logs during performance testing, I honestly do not want to do this because the performance tester is really generating live traffic which mimics a real time scenario. 3. How to set cron for rotating logs, I would think that this should be automatic. Would I need to do this everytime? 4. Do you have any way to increase performance of the amphora, my take is haproxy can handle several thousands of concurrent connections but in our case seems like we hit a threshold at 3500 - 4500 connections and then it starts to either send resets or the connections stay open for a long time. Thanks & Regards Prabhjit -----Original Message----- From: Singh, Prabhjit Sent: Tuesday, July 23, 2019 9:45 AM To: Michael Johnson <johnsomor(a)gmail.com> Cc: openstack-discuss(a)lists.openstack.org Subject: RE: [Octavia]-Seeking performance numbers on Octavia Thanks so much for the valuable insights Michael! Appreciate it and keep up the good work, as I ramp up with more dev know how hopefully I would start making contributions and can maybe convince my team to start as well. Thanks & Regards Prabhjit Singh -----Original Message----- From: Michael Johnson <johnsomor(a)gmail.com> Sent: Monday, July 22, 2019 5:48 PM To: Singh, Prabhjit <Prabhjit.Singh22(a)T-Mobile.com> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [Octavia]-Seeking performance numbers on Octavia [External] Hi Prabhjit, Comments in-line below. Michael On Sun, Jul 21, 2019 at 5:24 PM Singh, Prabhjit <Prabhjit.Singh22(a)t-mobile.com> wrote: > > Hi Michael, > > Thanks for taking the time out to send me your inputs and valuable suggestions. I do remember meeting you at the Denver Summit and hearing to a couple of your sessions. > If you wouldn't mind, I do have a few more questions and your answers would help me understand that should I continue to invest in having Octavia as one of our available LBs. > > 1. Based on your response and the amount of time you are investing in > supporting Octavia, what are some of the use cases, like for e.g. if load balancing web traffic how many transactions/connections minimum can be expected. I do understand you mentioned that it's hard to performance test Octavia but some real time situations from your testing and how customers have adopted Octavia would help me level set some expectations. This is really cloud and application specific. I would recommend you fire up an Octavia install and use your preferred tool to measure it. Some good tools are tsung, weighttp, and iperf3. > 2. We are thinking of Octavia as one of the offerings, that offers a self-serve type model. Do you know of any customers who have been able to use Octavia as one of their primary load balancers and any encouraging feedback you have gotten on Octavia. There are examples of organizations using Octavia available if you google Octavia. > 3. You suggested increasing the Ram size, I could go about making a whole new Flavor. Yes, to increase the allocated RAM for a load balancer, you would create an additional nova flavor with the specifications you would like. You can then either set this as the default nova flavor for amphora (amp_flavor_id is the setting) or you can create an Octavia flavor that specifies the nova compute flavor to use (See https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.open… for more information on Octavia flavors). > 4. I also noticed on the haproxy.conf the maxconns is set to 2000, should I increase this, does this affect the connection per server, which you said 64000 conns per server, so if I have 10 servers can I expect somewhere close to 640000 sessions? I think you are looking at the haproxy.conf file provided by your operating system package. Octavia does not use this file, it creates it's own HAProxy configuration files as needed under /var/lib/octavia inside the amphora. The default, if the user does not specify one at listener creation, is 1,000,000. > 5. Based on some of the limitations and the dev work in progress, I think the most important feature that would make Octavia a real solid offering would be the Active-Active and Autoscaling feature. I brought this up with you in our brief conversation at the summit, and you did mention that its not a top priority at this time and you are looking for some help. I have noticed a lot of documentation has been updated on this feature, do you think with the available document and progress I could spin up a distributor and manage sessions between Amphora or it's not complete yet. Active/Active is still on our roadmap, but unfortunately the people that were working on it had to stop for personal reasons. There may be some folks picking up this work again soon. At this point the Active/Active patches up for review are non-functional and still a work in progress. > 6. We have a Triple O setup, do you think I can make the above tweaks with the Triple O setup. I think you are able to make various adjustments to Octavia with Triple O, but I do not have specifics on that. > Thanks & Regards > > Prabhjit Singh > Systems Design and Strategy - Magentabox > | O: (973) 397-4819 | M: (973) 563-4445 > > > > -----Original Message----- > From: Michael Johnson <johnsomor(a)gmail.com> > Sent: Friday, July 19, 2019 6:00 PM > To: Singh, Prabhjit <Prabhjit.Singh22(a)T-Mobile.com> > Cc: openstack-discuss(a)lists.openstack.org > Subject: Re: [Octavia]-Seeking performance numbers on Octavia > > [External] > > > Hi Prabhjit, > > As you have mentioned, it is very challenging to get accurate performance results in cloud environments. There are a large number(very large in fact) of factors that can impact the overall performance of OpenStack and Octavia. > > In our OpenDev testing environment, we only have software emulation virtual machines available (Qemu running with the TCG engine) which performs extremely poorly. This means that the testing environment does not reflect how the software is used in real world deployments. > An example of this is simply booting a VM can take up to ten minutes on Qemu with TCG when it takes about twenty seconds on a real OpenStack deployment. > With this resource limitation, we cannot effectively run performance benchmarking test jobs on the OpenDev environment. > > Because of this, we don't publish performance numbers as they will not reflect what you can achieve in your environment. > > Let me try to speak to your bullet points: > 1. The Octavia team has never (to my knowledge) claimed the Amphora driver is "carrier grade". We do consider the Amphora driver to be "operator grade", which speaks to a cloud operator's perspective versus the previous offering that did not support high availability, have appropriate maintenance tooling, upgrade paths, performance, etc. > To me, "carrier grade" has an additional level of requirements including performance, latency, scale, and availability SLAs. This is not what the Octavia Amphora driver is currently ready for. That said, third party provider drivers for Octavia may be able to provide a "carrier grade" level of load balancing for OpenStack. > 2. As for performance tuning, much of this is either automatically handled by Octavia or are dependent on the application you are load balancing and your cloud deployment. For example we have many configuration settings to tune how many retries we attempt when interacting with other services. In performing and stable clouds, these can be tuned down, in others the defaults may be appropriate. If you would like faster failover, at the expense of slightly more network traffic, you can tune the health monitoring and keepalived_vrrp settings. We do not currently have a performance tuning guide for Octavia but would support someone authoring one. > 3. We do not currently have a guide for this. I will say with the version of HAproxy currently being shipped with the distributions, going beyond the 1vCPU per amphora does not gain you much. With the release of HAProxy 2.0 this has changed and we expect to be adding support for vertically scaling the Amphora in future releases. Disk space is only necessary if you are storing the flow logs locally, which I would not recommend for a performance load balancer (See the notes in the log offloading guide: > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.open…). > Finally, the RAM usage is a factor of the number of concurrent connections and if you are enabling TLS on the load balancer. For typical load balancing loads, the default is typically fine. However, if you have high connection counts and/or TLS offloading, you may want to experiment with increasing the available RAM. > 4. The source IP issue is a known issue > (https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstoryboar…). We have not prioritized addressing this as we have not had anyone come forward that they needed this in their deployment. If this is an issue impacting your use case, please comment on the story to that effect and provide a use case. This will help the team prioritize this work. > Also, patches are welcome! If you are interested in working on this issue, I can help you with information about how this could be added. > It should also be noted that it is a limitation of 64,000 connections per-backend server, not per load balancer. > 5. The team uses the #openstack-lbaas IRC channel on freenode and is happy to answer questions, etc. > > To date, we have had limited resources (people and equipment) available to do performance evaluation and tuning. There are definitely kernel and HAProxy tuning settings we have evaluated and added to the Amphora driver, but I know there is more work that can be done. If you are interested in help us with this work, please let us know. > > Michael > > P.S. Here are just a few considerations that can/will impact the performance of an Octavia Amphora load balancer: > > Hardware used for the compute nodes > Network Interface Cards (NICs) used in the compute nodes Number of > network ports enabled on the compute hosts Network switch > configurations (Jumbo frames, and so on) Cloud network topology > (leaf‐spine, fat‐tree, and so on) The OpenStack Neutron networking > configuration (ML2 and ML3 drivers) Tenant networking configuration > (VXLAN, VLANS, GRE, and so on) Colocation of applications and Octavia > amphorae Over subscription of the compute and networking resources > Protocols being load balanced Configuration settings used when > creating the load balancer (connection limits, and so on) Version of > OpenStack services (nova, neutron, and so on) Version of OpenStack > Octavia Flavor of the OpenStack Octavia load balancer OS and > hypervisor versions used Deployed security mitigations (Spectre, > Meltdown, and so on) Customer application performance Health of the > customer application > > On Fri, Jul 19, 2019 at 8:52 AM Singh, Prabhjit <Prabhjit.Singh22(a)t-mobile.com> wrote: > > > > Hi > > > > > > > > I have been trying to test Octavia with some traffic generators and > > my tests are inconclusive. Appreciate your inputs on the following > > > > > > > > It would be really nice to have some performance numbers that you guys have been able to achieve for this to be termed as carrier grade. > > Would also appreciate if you could share any inputs on performance > > tuning Octavia Any recommended flavor sizes for spinning up Amphorae, the default size of 1 core, 2 Gb disk and 1 Gig RAM does not seem enough. > > Also I noticed when the Amphorae are spun up, at one time only one > > master is talking to the backend servers and has one IP that its > > using, it has to run out of ports after 64000 TCP concurrent > > sessions, id there a way to add more IPs or is this the limitation > > If I needed some help with Octavia and some guidance around > > performance tuning can someone from the community help > > > > > > > > Thanks & Regards > > > > > > > > Prabhjit Singh > > > > > > > > > > > >

2 1

[tc] Campaign Question: Treating the Problem, not just the symptoms- Burnout, No Polling, etc
by Kendall Nelson 07 Sep '19

07 Sep '19

Hello :) Wanted to split the question Chris Dent asked here[1] into its own thread so people down the road and those tracking it now can find more easily. To kind of rephrase for everyone (Chris, correct me if I am wrong or not getting all of it): What do you think we, as a community, can do about the lack of candidates for roles like TC or PTL? How can we adjust, as a community, to make our governance structures fit better? In what wasy can we address and prevent burnout? I think JP[2] and Jay[3] already started to enumerate good ideas on the other thread, so to summarize/ expand/ add to their lists: - Reducing the number of TC members to 9, and maybe someday down to 7. When we were having polls for every election (maybe not every project) it was at a time where the electorate (and theoretically the number of possible candidates) was also huge. Since we have move past the hype curve and stabilized as a project, the number of polls we've (I say we because I used to be and still plan to help with elections) had to make have decreased. It seems to be a matter of proportions. - Continuing to improve education and onboarding process. Agreed 100%, but this should be an ongoing focus for everyone too- every contributor TC, PTL, or otherwise. The best way to get more people involved faster is a lower barrier to entry, but we all know that. Yes some things like gerrit and IRC are hard for people to get past and likely won't be changing for our community any time soon, but there are things like that with every community (I don't know if you have ever tried to push patches to k8s but their tagging of PRs is something they are working on making less complicated and better documented). Breaking down the onboarding process we have at the moment into smaller modules and clearly documenting the progression through those modules for new comers to easily find and work through is important. Also, though, having that be the only place that we, as a community, point to (meaning no duplicate information in multiple places like we have today) when new contributors have issues. - Better documentation of tribal knowledge. I proposed as a community goal for the U release[4], to formalize project specific onboarding information (some teams have already done this) and project specific guides for PTLs (I know we already have the broad strokes for all PTLs documented fairly well, but there's always project specific stuff) so that when there is a turn over mid release, its easier for someone new to step up. - Utilize the user survey to gather info about how/why contribution is happening or why they aren't contributing if that's the case. There are already several questions there from the TC about this topic in the survey, but perhaps they can be re-framed if we aren't getting the info we want from them. As a reminder, here they are: -- To which projects does your organization contribute maintenance resources, such as patches for bug fixes and code reviews on master or stable branches? -- What prevents you or your organization from contributing more maintenance resources, or makes contributing difficult? -- How do members of your organization contribute to OpenStack? I think the real issue is getting larger vendors of OpenStack to get their users to take the user survey. We have a pretty solid reach as it is, but there are a lot of people using OpenStack that don't take the survey that we don't know about even because they are confidential (their results can still be confidential if they take the survey). - Longer release cycle. I know this has come up a dozen or more times (and I'm a little sorry for bringing it up again), but I think OpenStack has stabilized enough that 6 months is a little short and now may finally be the time to lengthen things a bit. 9 months might be a better fit. With longer release cycles comes more time to get work done as well which I've heard has been a complaint of more part time contributors when this discussion has come up in the past. - Co-PTL type position? I've noticed and talked to several PTLs on a variety of projects that need a little extra help with the role. They either don't feel like they have all the experience they need to be PTL yet and so they want the previous PTL to help out still or maybe they want to do it, but there are enough variables in their day to day work (or lack of overlap tz wise with most of the other contributors to that project), that having a backup person to help out and backfill when they need help. - Talking to each other. I really honestly think just talking to one another could help too. When you find yourself in a conversation with someone about how unmotivated they are because they have a ton of work to do. You might offer to take something off their plate. Or help them see maybe they need to not take on anything new till some other work gets wrapped up. We are a community that succeeds together, so if you see someone burning themselves out do what you can to help lighten their load (helping directly is great, but there are plenty of other people in our community that you could call on to help too). Hopefully goes without saying, but don't burn yourself out trying to help someone else either. Some of these things are more actionable, others are still high level and need to have concrete actions tied to them, but I think there are plenty of things we can do to make progress here. -Kendall (diablo_rojo) [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00908… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00908… [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00910… [4] https://etherpad.openstack.org/p/PVG-u-series-goals

6 9

[neutron] CI issues
by Slawek Kaplonski 07 Sep '19

07 Sep '19

Hi neutrinos, We are currently having some issues in our gate. Please see [1], [2] and [3] for details. If Your Neutron patch failed on neutron-functional, neutron-functional-python27 or networking-ovn-tempest-dsvm-ovs-release jobs, please don’t recheck before all those issues will be solved. Recheck will not help and You will only use infra resources. [1] https://bugs.launchpad.net/neutron/+bug/1842659 [2] https://bugs.launchpad.net/neutron/+bug/1842482 [3] https://bugs.launchpad.net/bugs/1842657 — Slawek Kaplonski Senior software engineer Red Hat

1 1

[all][research] Survey for Openstack developers =)
by Farida El Zanaty 06 Sep '19

06 Sep '19

Hi!I am Farida from McGill University. I am trying to learn more about code reviews in the Openstack community, as I have been studying Openstack projects for a while. Please help me understand your perspective on design discussions during code reviews by filling up this 10-minute survey: https://forms.gle/Hhn191f6cxF5hVgG8 Survey participants will also be entered into a raffle for a $50 Amazon gift card. A little bit of context: Under the supervision of Prof. Shane McIntosh, my research aims to study design discussions that occur between developers during code reviews. Last year, we published a study about the frequency and types of such discussions that occur in OpenStack Nova and Neutron (http://rebels.ece.mcgill.ca/papers/esem2018_elzanaty.pdf<https://slack-redir.net/link?url=http%3A%2F%2Frebels.ece.mcgill.ca%2Fpapers…>).We are reaching out to Openstack developers to better understand their perspectives on design discussions during code reviews. Survey: https://forms.gle/Hhn191f6cxF5hVgG8<https://slack-redir.net/link?url=https%3A%2F%2Fforms.gle%2FHhn191f6cxF5hVgG8>Thanks for your time, Farida El-Zanaty =)

1 0

[all][tc] PDF Community Goal Update
by Akihiro Motoki 06 Sep '19

06 Sep '19

Hi all, I would like to share the status of the PDF community goal. We made great progresses these two weeks. Highlights ---------- It is time for working on the PDF community goal in your project! - openstack-tox-docs job supports PDF build now. AJaeger and I worked on the job support of PDF doc build and publishing and have completed it. - We confirmed PDF build with the sphinx latex builder works for several major projects like nova, cinder and neutron. The approach with the latex builder should work for most projects. - First PDF doc is now published from the i18n project. How to get started ------------------ - "How to get started" section in the PDF goal etherpad [1] explains the minimum steps. You can find useful examples there too. - To build PDF docs locally, you need to install LaTex related packages. See "To test locally" in the etherpad [1]. - If you hit problems during PDF build, check the common problems etherpad [2]. We are collecting knowledges there. - If you have questions, feel free to ask #openstack-doc IRC channel. Also Please sign up your name to "Project volunteers" in [1]. Useful links ------------ [1] https://etherpad.openstack.org/p/train-pdf-support-goal [2] https://etherpad.openstack.org/p/pdf-goal-train-common-problems [3] Ongoing reviews: https://review.opendev.org/#/q/topic:build-pdf-docs+(status:open+OR+status:… Thanks, Akihiro Motoki (amotoki)

9 15

[release][heat][nova][openstackclient][openstacksdk][nova] Pending final library releases
by Sean McGinnis 06 Sep '19

06 Sep '19

Hey everyone, Yesterday was the deadline for any non-client library releases. In order to make sure we include any unreleased commits, and to make sure those commits are able to make it onto a stable/train branch, releases were proposed by the Release Management team for any libs that looked like they needed it. We've had most of them +1'd by the team's PTL or release liaison and have been able to process those requests. There are still a few with no responses from the teams though. https://review.opendev.org/#/q/topic:train-3+status:open If you are a PTL or release liaison for one of the teams tagged in the subject line, please take a look and either +1 if things are ready, or if there are any last minute critical fixes going in, update the patches with a more appropriate commit hash to tag from. For any release requests not ack'd by the teams, we will need to proceed with these by Monday morning to make sure updates make it out and any dependency issues are flushed out before the client lib and other upcoming freezes. I will also submit patches to create the stable/train branch for any of these libs that have not already done so. If there are any questions or concerns about any of this, please reach out here or in the #openstack-release channel and we'll do what we can to help out. Thanks! Sean

1 0

[nova] Deprecating the XenAPI driver
by Matt Riedemann 06 Sep '19

06 Sep '19

After discussing this at the Train PTG and logging a quality warning in the driver 3 months ago [1] with no response, the nova team is now formally deprecating the XenAPI driver [2]. There has been no working third party CI for the driver for at least a release and no clear maintainers of the driver in nova anymore. If you're using the driver in production, please speak up now otherwise technically the driver could be removed as early as the Ussuri release. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006744.html [2] https://review.opendev.org/#/c/680732/ -- Thanks, Matt

1 0

[cinder][ops] Shanghai Forum - Cinder Topic Planning
by Brian Rosmaita 06 Sep '19

06 Sep '19

The Cinder Community would like to get in on some Forum action in Shanghai, but to do that we need to have some topics to propose. You don't have to actively be working on Cinder to propose a topic, and you don't have to be present to win. The point of the Forum sessions is to get feedback from operators and users about the current state of the software, get some ideas about what should be in the next release, and have some strategic discussion about The Future. So whether you can attend or not, if you have some ideas you'd like us to discuss, feel free to propose a topic: https://etherpad.openstack.org/p/cinder-shanghai-forum-proposals The deadline for proposals to the Foundation is 20 September, so if you could get your idea down on the etherpad before the Cinder weekly meeting on Wednesday 18 September 16:00 UTC, that will give the Cinder team time to look them over. thanks! brian

1 0

[tripleo] Proposing Damien Ciabrini as core on TripleO/HA
by Michele Baldessari 06 Sep '19

06 Sep '19

Hi all, Damien (dciabrin on IRC) has always been very active in all HA things in TripleO and I think it is overdue for him to have core rights on this topic. So I'd like to propose to give him core permissions on any HA-related code in TripleO. Please vote here and in a week or two we can then act on this. Thanks, -- Michele Baldessari <michele(a)acksyn.org> C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D

16 15

[goal][python3] Train unit tests weekly update (goal-1)
by Corey Bryant 06 Sep '19

06 Sep '19

This is the goal-1 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There is only 1 week remaining for completion of Train community goals [2]. == How can you help? == If your project has failing tests please take a look and help fix. Python 3.7 unit tests will be self-testing in Zuul. Failing patches: https://review.openstack.org/#/q/topic:python3-train +status:open+(+label:Verified-1+OR+label:Verified-2+) If your project has patches with successful tests please help get them merged. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3 -train+is:open Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Ongoing Work == We're down to 8 projects with failing tests that need fixing, and 3 projects with successful tests that should be ready to merge. I've been working to contact PTLs for these projects to help finish them up. Thank you to all who have contributed their time and fixes to enable patches to land! == Completed Work == All patches have been submitted to all applicable projects for this goal. Merged patches: https://review.openstack.org/#/q/topic:python3-train +is:merged == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals/train/ python3-updates.html [2] Train release schedule: https://releases.openstack.org/train /schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… train.rst Thanks, Corey

1 0

[monasca] Review Priority flag
by Witek Bedyk 06 Sep '19

06 Sep '19

Hello Team, now that we have the possibility to label our code changes with Review-Priority I would like to start the discussion about formalizing its usage. Right now every core reviewer can set its value, but we haven't defined any rules on how to use it. I suggest a process of proposing the changes which should be prioritized in weekly team meeting or in the mailing list. Any core reviewer, preferably from a different company, could confirm such proposed change by setting RV +1. I hope it's simple enough. What do you think? Another topic is exposing the prioritized code changes to the reviewers. We can list them using the filter [1]. We could add the link to this filter to Contributor Guide [2] and Priorities page [3]. We should also go through the list every week in the meeting. Any other ideas? Thanks Witek [1] https://review.opendev.org/#/q/(projects:openstack/monasca+OR+project:opens… [2] https://docs.openstack.org/monasca-api/latest/contributor/index.html [3] http://specs.openstack.org/openstack/monasca-specs/

2 1

[ironic] opensuse-15 jobs are temporary non-voting on bifrost
by Dmitry Tantsur 06 Sep '19

06 Sep '19

Hi all, JFYI we had to disable opensuse-15 jobs because they kept failing with repository issues. Help with debugging appreciated. Dmitry

2 2

[placement] update 19-35
by Chris Dent 06 Sep '19

06 Sep '19

HTML: https://anticdent.org/placement-update-19-35.html Let's have a placement update 19-35. Feature freeze is this week. We have a feature in progress (consumer types, see below) but it is not critical. # Most Important Three main things we should probably concern ourselves with in the immediate future: * We are currently without a PTL for Ussuri. There's some discussion about the options for dealing with this in an [email thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-Septemb…. If you have ideas (or want to put yourself forward), please share. * We need to work on useful documentation for the features developed this cycle. * We need to create some [cycle highlights](http://lists.openstack.org/pipermail/openstack-discuss/2019-Sep…. To help with that I've started [an etherpad](https://etherpad.openstack.org/p/placement-train-cycle-highlights). If I've forgotten anything, please make additions. # What's Changed * osc-placement 1.7.0 has been [released](https://pypi.org/project/osc-placement/). This adds support for [managing allocation ratios](https://review.opendev.org/#/q/topic:allocation-ratios+(status:open… via aggregates, but adding a few different commands and args for inventory manipulation. * Work on consumer types exposed that placement needed to be first class in grenade to make sure database migrations are run. That [change has merged](https://review.opendev.org/679655). Until then placement was upgraded as part of nova. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 24 (-1) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 5 (0) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 4 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (-1) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 17 (0). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 6 (0). # osc-placement * <https://review.opendev.org/666542> Add support for multiple member_of. There's been some useful discussion about how to achieve this, and a consensus has emerged on how to get the best results. * `--amend` and `--aggregate` on resource provider inventory has merged and been release 1.7.0 (see above). # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> I took this through to microversion and api-ref docs, so it is ready for wider review. If this doesn't make it in for Train, that's okay. The goal is to have it ready for Nova to start working with it when Nova is able. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. Performance related explorations continue: * <https://review.opendev.org/#/c/679385/> Refactor initialization of research context. This puts the code that might cause an exit earlier in the process so we can avoid useless work. One outcome of the performance work needs to be something like a _Deployment Considerations_ document to help people choose how to tweak their placement deployment to match their needs. The simple answer is use more web servers and more database servers, but that's often very wasteful. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. * <https://review.opendev.org/676982> Merge request log and request id middlewares is worth attention. It makes sure that _all_ log message from a single request use a global and local request id. There are three [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And zero [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class…. # Other Service Users This week (because of feature freeze) I will not be adding new finds to the list, just updating what was already on the list. * <https://review.opendev.org/662229> helm: add placement chart * <https://review.opendev.org/#/q/topic:bp/virtual-persistent-memory> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/670112> Nova: WIP: Add a placement audit command * <https://review.opendev.org/671793> Nova: libvirt: Start reporting PCPU inventory to placement A part of <https://review.opendev.org/#/q/topic:bp/cpu-resources> * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/670696> tempest: Add placement API methods for testing routed provider nets * <https://review.opendev.org/672678> openstack-helm: Build placement in OSH-images * <https://review.opendev.org/674129> Correct global_request_id sent to Placement * <https://review.opendev.org/#/q/topic:bp/cross-cell-resize> Nova: cross cell resize * <https://review.opendev.org/674524> Nova: Scheduler translate properties to traits * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/#/q/topic:bp/provider-config-file> Nova: using provider config file for custom resource providers # End 🐎 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[keystone][horizon][zaqar][tempest][requirements] library updates breaking projects
by Matthew Thode 06 Sep '19

06 Sep '19

I emailed a while ago about problem updates and wanted to give an update. I'm hoping we can get these fixed before the freeze which is on Monday iirc. horizon This is a newer issue which e0ne and amotoki know about but no existing review to fix it. please test against https://review.opendev.org/680457 -semantic-version===2.8.1 +semantic-version===2.6.0 tempest STILL has failures I thought the following commit would fix it, but nope https://github.com/mtreinish/stestr/commit/136027c005fc437341bc23939a18a5f3… -stestr===2.5.1 +stestr===2.4.0 python-zaqarclient waiting on https://review.opendev.org/679842 may be merging today -jsonschema===3.0.2 +jsonschema===2.6.0 keystone a review is out there that seems to have tests passing https://review.opendev.org/677511/ -oauthlib===3.1.0 +oauthlib===3.0.2 -- Matthew Thode

2 1

[cloudkitty] Shift IRC meeting of september 6th
by Luka Peschke 06 Sep '19

06 Sep '19

Hello, Some CK cores are unavailable today, so we've decided to move today's meeting to next friday (the 13th) at 15h UTC / 17h CEST . Regards, Luka Peschke

1 0