April 2019 - openstack-discuss - lists.openstack.org

[openstack-ansible] Documentation of host OS major upgrade
by Gilles Mocellin 13 Apr '19

13 Apr '19

Hello, I'm actually using OpenStack-Ansible to deploy a little public cloud. For now it runs on Queens / Ubuntu 16.04. I've read that Rocky will be the only release supported on both Ubuntu 16.04 and Ubuntu 18.04 with OpenStack-Ansible. Stein being out soon (with OpenStack-Ansible), the question of Host OS upgrade from Ubuntu 16.04 to ubuntu 18.04 is a big thing of this year. I've not found any documentation about that upgrade path (Rocky->Stein, host OS). I had some answers on IRC that OpenStack Ansible does not support a mixed environnement (adding compute nodes on Ubuntu 18.04 while the rest is on Ubuntu 16.04 for example). Did I miss something in the actual doc or in some blogs ? I'm sure some users already faced this with transition fro Ubuntu 14.04 to Ubuntu 16.04. There's certainly some material to start some documentation and add it to https://docs.openstack.org/openstack-ansible/stein/admin/upgrades/ major-upgrades.html. I know that there's less contributors now, I'll see if I can help. Thanks.

3 3

[release][stable][trove] Please add Lingxian Kong to trove-stable-maint group
by Lingxian Kong 13 Apr '19

13 Apr '19

Hi Stable Maintenance Core team, I'm current Trove PTL, could you please add myself to trove-stable-maint so that I could merge those patches[1][2][3] for stable/stein? [1] https://review.openstack.org/#/c/645647/ [2] https://review.openstack.org/#/c/645646/ [3] https://review.openstack.org/#/c/645648/ --- Cheers, Lingxian Kong Catalyst Cloud

5 19

[dev][stable][release][manila] Should we revert these stable branch backports?
by Tom Barron 13 Apr '19

13 Apr '19

In manila we recently merged backports of a change [1] that aims to fix up faulty configuration option deprecations in the Dell-EMC VMAX driver. The question at hand is whether (a) we should revert these backports on the grounds that the deprecations were faulty and therefore are only effective from Stein forwards, or whether (b) the deprecations actually worked and took effect back when Ocata was the development branch but had faults that should be corrected all the way back to Pike before it goes EM. I think (b) is the correct answer but let's check. On Jan 10 2017 a review [2] merged that deprecated generic Dell-EMC driver options in favor of model-specific options [2]. There were two models at the time, Unity and VNX. This change was in itself unproblematic. On Jan 24 2017 a review [3] merged that introduced a third Dell-EMC model, VMAX. This new code introduced VMAX specific options, consistent with the deprecation of the generic Dell-EMC options. However it had two problems which review [1] corrects. When it defined the new VMAX-specific options it failed to indicate the corresponding old generic options via 'deprecated_name' [4]. Worse, the code that consumed the options actually looked for the old generic 'emc_interface_ports' option instead of the new 'vmax_ethernet_ports' option. The only way to set a value for this option was to use its deprecated form. The change that we backported fixes both of these problems. I think it is a valid stable backport. If people set this "ports" option using the deprecated option it will still work. The deprecated option has not been removed yet and will never be removed from any of the stable branches. If they tried to set it via the proper option then they would have had a functional problem, a bug, which this change now fixes. If on the other hand we say we cannot backport this then until stable/stein there will be no way for VMAX users of earlier stable branches to set this option except by magic -- by using an old deprecated form of the option that without the backported fix is not even visible in the customer-facing configuration for VMAX. All this said, I could well be missing something so I welcome analysis by stable/core folks. The backports in question have not yet been released so it would not be a problem to revert them. Thanks! -- Tom Barron [1] https://review.openstack.org/#/c/608725/ [2] https://review.openstack.org/#/c/415079/ [3] https://review.openstack.org/#/c/404859/ [4] If this was the only issue then arguably it wasn't an error since the VMAX driver never operated with the old options.

3 9

[Zun] Heat and Horizon Support
by Navdeep Uniyal 13 Apr '19

13 Apr '19

Dear All, I would like to integrate my Zun deployment (OS Rocky) with Heat and Horizon. For horizon, I used the instructions given in https://docs.openstack.org/zun-ui/rocky/install/index.html However, while adding the files to /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled Using : cp zun_ui/enabled/* /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled My openstack UI is breaking down : [cid:image001.jpg@01D4EFB9.89E6F5B0] Please advise. Kind Regards, Navdeep

3 4

[dev][keystone] Keystone Team Update - Week of 8 April 2019
by Colleen Murphy 12 Apr '19

12 Apr '19

# Keystone Team Update - Week of 8 April 2019 ## News ### Stein Release Keystone has been released for Stein! Congrats on a great release! ### Predictable IDs We're starting to move forward[1][2][3][4] with Adam's predictable IDs initiative[5], including discussing[6] whether and how to migrate deployments to using hashed IDs so that they can become multi-site ready. [1] https://review.openstack.org/605169 [2] https://review.openstack.org/650615 [3] https://review.openstack.org/605235 [4] https://review.openstack.org/651655 [5] https://review.openstack.org/612099 [6] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ### Admin endpoint Jens is working on getting us on track to remove the admin endpoint from deployments[7][8], since keystone is the only service that uses it and it's no longer needed in a V3-only world. There are a few hardcoded defaults that make the switchover less than straightforward that we're working out[9]. [7] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… [8] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… [9] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh Train specs have begun! Please review the open spec proposals so we can discuss them at the PTG. ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 31 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 24 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 2 new bugs and closed 4. Bugs opened (2) Bug #1823847 (keystone:Undecided) opened by Shivakumar M https://bugs.launchpad.net/keystone/+bug/1823847 Bug #1824239 (keystone:Undecided) opened by Adam Young https://bugs.launchpad.net/keystone/+bug/1824239 Bugs closed (1) Bug #1823847 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1823847 Bugs fixed (3) Bug #1779889 (keystone:Medium) fixed by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1779889 Bug #1641639 (keystone:Wishlist) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1641639 Bug #1794527 (keystone:Wishlist) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1794527 ## Milestone Outlook https://releases.openstack.org/train/schedule.html The Train cycle will open next week. We'll need to decide on deadlines for the cycle soon. ## Shout-outs Thanks everyone for making this a great release! Looking forward to seeing what we can accomplish next cycle :) ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

Upgrading the lists.(openstack|airshipit|starlingx|zuul-ci).org server Friday April 12
by Clark Boylan 12 Apr '19

12 Apr '19

It is that time of the Ubuntu LTS cycle again and we need to upgrade our mailman mailing list server. We'd like to do that this Friday, April 12. We expect the upgrade to begin at about 17:00UTC and result in a 30-45 minute outage. The reason for the extended outage is that we will be upgrading the server in place to preserve its mail reputation. Thankfully email is a persistent system and your clients should queue up email sent until the server is back up again and accepting smtp connections. This means the outage shouldn't be very noticeable. Finally, for list admins, there are new DMARC moderation action settings. We ask that you don't change these settings and instead work with us if you need to address DMARC problems. Our current preference is that we pass email through unmodified so that the signatures still validate. Thank you all for your patience and feel free to ask us questions, Clark

1 1

[placement] update 19-14
by Chris Dent 12 Apr '19

12 Apr '19

HTML: https://anticdent.org/placement-update-19-14.html Placement update 19-14 is here. There will be no 15, 16 or 17 due to various bits of travel. There will be some PTG-related summaries. # Most Important The [Virtual Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/… is in full swing and making some good progress towards making sure that we only hit the hard stuff at the in-person PTG. Apologies if it has been a bit overwhelming. The hope is that by paying the price of a bit more whelm now we will have less whelm at the PTG. If you have questions, please ask. Links to all the threads are in the PTG etherpads: * <https://etherpad.openstack.org/p/placement-ptg-train> * <https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement> There's also a [retrospective etherpad](https://etherpad.openstack.org/p/placement-ptg-train-retrospectiv…. # What's Changed * The [0.12.0 release of os-traits](https://review.openstack.org/652079) is pending. It switches that package to using the independent release policy. os-resource-classes will get the same treatment when we next need to release it. # Specs/Features There are four specs in flight in the placement repo and one pending to be ported over from nova: * <https://review.openstack.org/649992> support any trait in allocation candidates * <https://review.openstack.org/649368> support mixing required traits with any traits * <https://review.openstack.org/650476> Allocation Candidates: Subtree Affinity. There's discussion related to this happening in [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/00… as part of the pre-PTG. * <https://review.openstack.org/651113> Support filtering by multiple trees. * <https://review.openstack.org/597601> Request group mapping spec is still in Nova, but discussion is happening in [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/00… generating a plan for how to proceed. There are also several nova-specs that were visited in the [nova spec review day](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/0044… earlier this week. Some are listed below. # Bugs * StoryBoard stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement): 15. Up by 9. 0 are [untagged](https://storyboard.openstack.org/#!/worklist/580). Part of the reason for the increase is because Matt did the fine work of moving osc-placement bugs over from launchpad. * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 13. No change. * [In progress placement bugs](https://goo.gl/vzGGDQ) on launchpad: 4. -1. Those that remain are placement-related, but in nova. # osc-placement osc-placement is currently behind by 13^w11 microversions. -1 since last week. Support for 1.19 has just merged. Oh wait, no, -3. 1.21 has just merged. There was nothing to do for 1.20. Pending changes: * <https://review.openstack.org/#/c/640898/> Add 'resource provider inventory update' command (that helps with aggregate allocation ratios). * <https://review.openstack.org/#/c/651783/> Add support for 1.22 microversion * <https://review.openstack.org/586056> Provide a useful message in the case of 500-error * <https://review.openstack.org/650257> Remove unused cruft from doc and releasenotes config * <https://review.openstack.org/652100> Improve aggregate version check error messages with min_version * <https://review.openstack.org/651939> Use PlacementFixture in functional tests. Result of discussion in [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/00… in the pre-PTG # Main Themes More work remains in the pre-PTG discussions to try to drive towards some themes. The specs above capture some of it, but it appears like a lot of the work will be a) supporting other projects doing things with Placement, b) fixing bugs they discover. # Other Placement Mostly specs in progress (listed above) for now. * <https://review.openstack.org/#/c/645255/> This is a start at unit tests for the PlacementFixture. It is proving a bit "fun" to get right, as there are many layers involved. Making sure seemingly unrelated changes in placement don't break the nova gate is important. Besides these unit tests, there's discussion on the PTG etherpad of running the nova functional tests, or a subset thereof, in placement's check run. On the one hand this is a pain and messy, but on the other consider what we're enabling: Functional tests that use the real functionality of an external service (real data, real web requests), not stubs or fakes. There's a pre-PTG [thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/0… for this. * <https://review.openstack.org/641404> Use ``code`` role in api-ref titles * <https://review.openstack.org/#/q/topic:refactor-classmethod-diaf> A sequence of refactorings, based off discussion in yet another pre-PTG [thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/0…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/555081> Nova: Spec: Standardize CPU resource tracking * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/606199> Ironic: A fresh way of looking at step retrieval * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/640080> Nova: Use aggregate_add_host in nova-manage * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/624335> puppet-tripleo: Initial extraction of the Placement service from Nova * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/#/c/642067/> Helm: Allow more generic overrides for nova placement-api * <https://review.openstack.org/609960> Support filtering of allocation_candidates by forbidden aggregates * <https://review.openstack.org/625284> Cyborg: Initial readme for nova pilot * <https://review.openstack.org/629142> Tempest: Add QoS policies and minimum bandwidth rule client * <https://review.openstack.org/641994> Nova-spec: Re-approve AMD SEV support for Train * <https://review.openstack.org/648687> Nova-spec: Add PENDING vm state * <https://review.openstack.org/#/q/topic:bug/1777591> Nova: use in_tree in RequestGroup * <https://review.openstack.org/650856> kolla-ansible: Remove placement migration code * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.openstack.org/651024> nova-spec: RMD Plugin: Energy Efficiency using CPU Core P-State control * <https://review.openstack.org/651455> puppet: Debian: Add support for placement-api over uwsgi * <https://review.openstack.org/650963> nova-spec: Proposes NUMA affinity for vGPUs. This describes a legacy way of doing things because affinity in placement may be a ways off. But it also [may not be](https://review.openstack.org/650476). * <https://review.openstack.org/649882> nova-spec: Separate the vCPUs into different pools based on priority * <https://review.openstack.org/#/q/topic:heal_allocations_dry_run> Nova: heal allocations, --dry-run * <https://review.openstack.org/642527> Neutron: Fullstack test for placement sync # End There's a lot going on. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

"Open Infrastructure & Cloud Native Days Korea 2019" is looking for Sponsors and Speakers
by Ian Y. Choi 12 Apr '19

12 Apr '19

Dear OpenStack Community Members, This year, I would like to announce that there will be "Open Infrastructure & Cloud Native Days Korea 2019" in Korea , with tight collaboration with Kubernetes & Ceph Korea User Groups (July 18th - 19th)! This is the sixth event succeeding from the first OpenStack Days Korea event in 2014. Each of five previous events had a huge success and attracted lots of interest among IT expert, engineers, developers and Executives. The event will be held on three near-buildings at Eulji-ro area in Seoul. There will be various keynotes, presentations, hands-on-labs,and attractive keynotes on timely and in-depth technologies and solutions. In order to successfully execute this event, we will need your help on both sponsoring and your participation on the event. https://openinfradays.kr/index_en.html In the above event webpage, you will find link for both “Sponsorship” and “Call for Speakers”. Please kindly review and consider sponsorship, and get back to us. If you have any question, you can contact one of organizers in OpenInfra Days Korea & Cloud Native Days Korea 2019 event stated at the end of this email. In addition, if you are interested in speaking at the event, please fill the form at “Call for Speakers” link (or please directly visit to Google Form : https://goo.gl/forms/ovsT0zQVauLaDlHg2 ) Thank you very much in advance, and we look forward to working with you. Best Regards, OpenStack Korea User Group – Ian Y. Choi (ianyrchoi at gmail.com) Kubernetes Korea User Group Leader: Seungkyu Ahn (seungkyua at gmail.com) Ceph Korea User Group Leader: Seungjin Han (yongiman at gmail.com) Program Chair – Jaesuk Ahn (bluejay.ahn at gmail.com) Event Organizing Chair – Jungwon Ku (jwon.ku at gmail.com)

1 0

[osprofiler] Distributed tracing in OpenStack
by Ilya Shakhat 12 Apr '19

12 Apr '19

Hi, Distributed tracing is one of must-have features when one wants to track the full path of request going through different services and APIs. This makes it similar to shared request-id, but with nice visualization at the end [1]. In OpenStack the tracing can be achieved via osprofiler library. The library was introduced 5 years ago, and back then there was no standard approach on how to do tracing and that's why it stays aside from what has become a mainstream. Yet there is no single standard, but the major players are OpenTracing and OpenCensus communities. OpenTracing is represented by Uber's Jaeger which is the default tracer from k8s world. Issues and limitations to be fixed: 1. Compatibility. While osprofiler library supports many different storage drivers, it has only one way of transferring trace context over the wire. Ideally the library should be compatible with other third-party tracers and allow traces to start in front of OpenStack APIs (e.g. in user apps) and continue after (e.g. in storage systems, or network management tools). [2] 2. Operation mode. With osprofiler tracing is initiated by user request, while in industrial solutions the tracing can be managed centrally via dynamic sampling policies. 3. In-process trace propagation. Depending on execution model (threaded, async) the ways of storing current trace context differ. OSProfiler supports thread-local model, which recently got broken with new async implementation in openstacksdk [3]. With OpenTracing it is possible to select the appropriate model alongside with tracer configuration. What's the plan: Switching to OpenTracing could be a good option to gain compatibility with 3rd-party solutions. The actual change should go to osprofiler library, but indirectly affects all OpenStack projects (should it be a global team goal then?). I'm going to make a PoC of proposed change, so reviews would be highly appreciated. Comments, suggestions? Thanks, Ilya [1] e.g. http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-re… [2] https://bugs.launchpad.net/osprofiler/+bug/1798565 [3] https://bugs.launchpad.net/osprofiler/+bug/1818493

4 4

[placement][nova][ptg] Protecting driver-provided traits
by Chris Dent 12 Apr '19

12 Apr '19

>From the etherpad [0]: * We might want to tighten up what the RP traits API allows as per https://pasteboard.co/I3iqqNm.jpg * although maybe this is better covered in a nova session? * If the mechanism is changing how nova-compute reports and manipulates traits, then yeah, nova. But if for some reason there is a need to change the actual API [1], placement; but I would hope that all avenues not involving changing the API were first disposed as either not possible, or really really terrible. This came up as part of the work on compute capabilities as traits [2] and questions about who owns what traits and how to manage them so that unexpected trait clobbering or trait addition happens. This is (hopefully) mostly a thing on the nova-compute side of the equation (when managing inventory), so hopefully someone with more insight into that situation can drive this thread. What needs to happen here? [0] https://etherpad.openstack.org/p/placement-ptg-train [1] There are degrees of change in the API. Adding a query parameter is much less of a big deal than adding or changing an attribute in a request or response body. Adding another method to a URI, while a big deal in some cases, is much less of a big deal than adding an entirely new URI. [2] https://review.openstack.org/#/c/538498/k -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 7