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

[fenix][forum][ptg]
by Juvonen, Tomi (Nokia - FI/Espoo) 17 Apr '19

17 Apr '19

Hi, If you did not yet know Fenix: Fenix - rolling infrastructure maintenance and upgrade with VNF interaction to guarantee zero impact. https://wiki.openstack.org/wiki/Fenix Now there has been the rolling OpenStack upgrade with zero impact to VNF showcased in ONS America two weeks ago and it is time to look the Train and the way forward. Most importantly to harmonize with ETSI NFV and prioritize the work to have a solid base after this cycle. Here is etherpad for the forum: Fenix project update, future, discuss Tue 30th April, 9:00am - 9:40am The Colorado Convention Center - Ballroom Level - 4B https://etherpad.openstack.org/p/DEN-fenix-forum-brainstorming Here are etherpads for the PTG: Fenix and ETSI NFV synch: Sat 4th May, 10:00am - 11:00am https://etherpad.openstack.org/p/DEN2019-fenix-ETSI-NFV-PTG Fenix Train PTG, What to do next, prioritizing Sat 4th May, 11:10am - 12:10am https://etherpad.openstack.org/p/DEN2019-fenix-PTG br, Tomi

1 0

[telemetry] Nominating Rong Zhu for Telemetry core
by Trinh Nguyen 17 Apr '19

17 Apr '19

Hi team, I'd like to nominate Rong Zhu (zhurong) to become a Telemetry core. Rong Zhu has been contributing to OpenStack for a while now [1] and sometimes jump in to help Telemetry projects fix bugs. While being the PTL of Murano and Solum projects [2], his experience and network of developers working on ceilometer/aodh projects would be a huge benefit for the team. [1] https://review.openstack.org/#/q/owner:%22zhurong+%253Caaronzhu1121%2540gma… [2] https://governance.openstack.org/election/results/train/ptl.html Let give +1 for your agreement. Yours, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

3 3

[telemetry] Update cores team and team lead recruitment
by Trinh Nguyen 17 Apr '19

17 Apr '19

Hi team, As you may know, existing core members of Telemetry cannot work on the projects anymore. So, I would like to set up a new core team for Telemetry projects in the Train cycle. At the moment, only Lixian Kong and I have the core privileges over Ceilometer, AODH, and Panko projects. I expect to have 1 more core reviewer to help maintain Telemetry. So *please send us your proposal if you're interested*. This is the current structure of Telemetry: - AODH: Lixian Kong is the team lead - Ceilometer and Panko: myself. This is just tempory until we can find someone that has enough experience and willing to take the role. As discussed in yesterday meeting [1], you may argue that having experience does not necessarily qualify for code contributions but with the current situation, I would propose "*the willing to help*" as the number 1 criteria. We will move forward with it and fix processes when we see issues. Thank all the people that want to keep Telemetry alive. Yours, [1] https://etherpad.openstack.org/p/telemetry-train -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

4 8

[charms] OpenStack Charms 19.04 release is available with Stein enablement
by David Ames 17 Apr '19

17 Apr '19

The OpenStack Charms development team is happy to announce the 19.04 charms release, introducing support for OpenStack Stein with Ceph Mimic on Ubuntu 18.04 (LTS) and Ubuntu 19.04. This charm release also brings several new and valuable features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, and many other stable combinations of Ubuntu + OpenStack. For the full release notes, please reference: https://docs.openstack.org/charm-guide/latest/1904.html Some highlights: * Masakari instance high-availability * Keystone SSO/SAML integration * Nova GPU and general device pass-through * Multi-site replication between Ceph RADOS Gateways * Mirroring of RBD images across Ceph Clusters The charms dev team is available on Freenode #openstack-charms, and will be at the Open Infrastructure Summit and PTG events in Denver, CO (May 2019). Huge thanks to the 71 charm contributors who worked together to squash 247 bugs, to enable an entirely new charmed version of OpenStack, and to move the line forward on several key features! Ryan Beisner Frode Nordahl Liam Young James Page Doug Hellmann David Ames Corey Bryant Chris MacNaughton Paul Goins Pete Vander Giessen Alex Kavanagh Edward Hope-Morley melissaml Chris MacNaughton Sahid Orentino Ferdjaoui zhouxinyong Andreas Jaeger lijunjie Felipe Reyes caoyuan zhulingjie Vladimir Grevtsev Dmitrii Shcherbakov inspurericzhang Andrew McLeod Syed Mohammad Adnan Karim Andre Ruiz Tiago Pasqualini Billy Olsen Drew Freiberger Seyeong Kim Hua Zhang Vu Cong Tuan wanghui Trent Lloyd Przemyslaw Hausman xulei Andrea Ieri Xav Paice Alvaro Uria Tytus Kurek Nikolay Vinogradov lvxianguo Nobuto Murata Nicolas Pochet Aymen Frikha Marian Gasparovic lei zhang Niels van Adrichem andy wang Shane Peters Jonathan Herlin Andrey Grebennikov wangyayan zhangbailin Diko Parvanov Dimos Alevizos Mike Wilson David Coronel Tilman Baumann MaoyangLiu gaobin Jesper M Gábor Mészáros Junien Fridrick Pedro Guimarães Wouter van Bommel Abhijeet Patra Peter Zhang Barry Price Dongdong Tao -- OpenStack Charm Team

1 0

[cinder][dev] support-revert-to-any-snapshot
by Walsh, Helen 17 Apr '19

17 Apr '19

To cinder driver developers: * https://blueprints.launchpad.net/cinder/+spec/support-revert-to-any-snapshot In relation to the blueprint above. I am wondering if there are any drivers that whose later snapshots will not be valid after a revert to an snapshot that is NOT the last in the series Vol1 \ ----------------------------------------------------- Mon Tue Wed Thu Fri \ \ \ \ \ S1 -------- S2 ---------S3 -------- S4 ---------S5 If on Fri, I was to revert back to Tuesday's Snapshot S2, would S3, S4 and S5 still be usable Snapshots? Vol1 \ ----------------------------------------------------- Mon Tue Wed Thu Fri \ \ \ \ \ S1 -------- S2 ---------S3 -------- S4 ---------S5 Thank you, Helen

2 1

[PTG] FINAL SCHEDULE..NO SERIOUSLY.
by Kendall Nelson 17 Apr '19

17 Apr '19

Since I published the first 'Final Schedule' we have had a number of small changes that we've had to make so I wanted to update everyone to make sure we are all on the same page. Seriously though, this is the last round of changes as this version of the schedule has already gone to the design team and is going to print sometime tomorrow/Friday. To textually summarize the changes: - Tacker will no longer be meeting - Converted the Interop WG into a dynamically scheduled team - Horizon will be all day Thursday instead of a half day See you all soon! -Kendall (diablo_rojo)

1 0

Does anyone care about reviewstats?
by Matt Riedemann 17 Apr '19

17 Apr '19

There are open reviewstats changes [1] but the non-infra core team is entirely made up of people that no longer work on openstack [2]. I had a change that was open so long some of the projects are now owned by placement [3] so I just abandoned it. So the question is, does anyone use reviewstats anymore? If so, we should probably just start adding new people to the core team that actually use it. Otherwise we should probably just put it in the attic and rely on stackalytics (which is probably what most people are already doing). [1] https://review.openstack.org/#/q/project:openstack-infra/reviewstats+status… [2] https://review.openstack.org/#/admin/groups/893,members [3] https://review.openstack.org/#/c/499197/ -- Thanks, Matt

11 15

[all] Gerrit will be offline April 19, 2019
by Anita Kuno 17 Apr '19

17 Apr '19

Pursuant to this email thread: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.ht… , which discusses the rationale for moving git repo namespaces, Gerrit will be offline on April 19, 2019. Specific start time for the outage will be posted to this thread when it is decided next week. Outage may be sporadic as needed by the infra team, you can follow the progress in the #openstack-infra irc channel on freenode. Please review the above linked email and all the subsequent posts, and please post any concerns about the rationale or details to the above thread. If you have concerns about the Gerrit outage scheduled to begin April 19, 2019, please reply to this thread and/or join us in #openstack-infra on freenode to share your questions or concerns. Thank you, Anita

1 2

[placement][ptg] JSON payload for GET /a_c
by Chris Dent 17 Apr '19

17 Apr '19

>From the etherpad [1] * would make things like "resource provider affinity" above easier. much easier. and let us express granular-ness less awkwardly, and let us add new and richer group_policy concepts (which is basically the affinity thing). * Brought up briefly in the above spec at https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2… As clients making GET /allocation_candidates queries desire to express more and more complexity [2], query parameters start to feel cumbersome. At various times people have suggest that a JSON body might be easier to manage. The first time was during the discussion that resulted in the creation of the allocation_candidates resource. My personal feeling on this is that if we have a way to satisfy a use case without changing the API, even if it is cumbersome, we should write in that mode first and then decide if adding the other way is appropriate. This isn't simply because of some over-adherence to YAGNI, but because we need to deliver on some of placement's promise sooner than later and there don't seem to be a lot of people around. There may, however, be plenty of reasons that not everyone knows for why this needs to happen. If so, please share them. Only once we know those reasons should we start considering formats. What do we need to express (and why do we need to express it) that we can't express now? [1] https://etherpad.openstack.org/p/placement-ptg-train [2] https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resourc… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 4

[placement][ptg] Resource Provider Partitioning
by Chris Dent 17 Apr '19

17 Apr '19

>From the etherpad [1]: * do we need this? * what is it? * who is going to drive it? As as I recall, resource provider partitioning (distinct from allocation partitioning) is a way of declaring that a set of resource providers are in a thing. This would allow, for example, one placement to service multiple OpenStack clouds or for a placement to be a part of a single pane of glass system in a FOG or edge setup. This was mentioned during Stein nova discussions [2] but since then I've not personally heard a lot of discussion on this topic so it's unclear if it is a pressing issue. Do we want to be build it so they come, or wait until they come and then build it? The discussion at [2] mentions the possibility of an 'openstack-shard' header (instead of query parameter) that would be sent with any request to placement. There is, however, no substantive discussion on the internal implementation. Options: * Do nothing (see above) * Internally manipulate aggregates (all these resource providers below to shard X). * Add a 1:1 or 1:N relation between an RP and a shard uuid in the DB. * Use a trait! [3] But before we get into implementation details we should discuss the use cases for this (if any), the need to do it (if any), and the people who will do it (if any). All three of those are thin at this point. [1] https://etherpad.openstack.org/p/placement-ptg-train [2] around lines 243 on https://etherpad.openstack.org/p/nova-ptg-stein where both types (allocation/rp) of partitioning are discussed. [3] Not for the trait strict constructionists. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 13