- openstack-discuss - lists.openstack.org

[dev][keystone] Launchpad blueprint reckoning
by Lance Bragstad 15 Feb '19

15 Feb '19

Over the last couple of years, our launchpad blueprints have grown unruly [0] (~77 blueprints a few days ago). The majority of them were in "New" status, unmaintained, and several years old (some dating back to 2013). Even though we've been using specifications [1] for several years, people still get confused when they see conflicting or inaccurate blueprints. After another person tripped over a duplicate blueprint this week, cmurphy, vishakha, and I decided to devote some attention to it. We tracked the work in an etherpad [2] - so we can still find links to things. First, if you are the owner of a blueprint that was marked as "Obsolete", you should see a comment on the whiteboard that includes a reason or justification. If you'd like to continue the discussion about your feature request, please open a specification against the openstack/keystone-specs repository instead. For historical context, when we converted to specifications, we were only supposed to create blueprints for tracking the work after the specification was merged. Unfortunately, I don't think this process was ever written down, which I'm sure attributed to blueprint bloat over the years. Second, if you track work regularly using blueprints or plan on delivering something for Stein, please make sure your blueprint in Launchpad is approved and tracked to the appropriate release (this should already be done, but feel free to double check). The team doesn't plan on switching processes for feature tracking mid-release. Instead, we're going to continue tracking feature work with launchpad blueprints for the remainder of Stein. Currently, the team is leaning heavily towards using RFE bug reports for new feature work, which we can easily switch to in Train. The main reason for this switch is that bug comments are immutable with better timestamps while blueprint whiteboards are editable to anyone and not timestamped very well. We already have tooling in place to update bug reports based on commit messages and that will continue to work for RFE bug reports. Third, any existing blueprints that aren't targeted for Stein but are good ideas, should be converted to RFE bug reports. All context from the blueprint will need to be ported to the bug report. After a sufficient RFE bug report is opened, the blueprint should be marked as "Superseded" or "Obsolete" *with* a link to the newly opened bug. While this is tedious, there aren't nearly as many blueprints open now as there were a couple of days ago. If you're interested in assisting with this effort, let me know. Fourth, after moving non-Stein blueprints to RFE bugs, only Stein related blueprints should be open in launchpad. Once Stein is released, we'll go ahead disable keystone blueprints. Finally, we need to overhaul a portion of our contributor guide to include information around this process. The goal should be to make that documentation clear enough that we don't have this issue again. I plan on getting something up for review soon, but I don't have anything currently, so if someone is interested in taking a shot at writing this document, please feel free to do so. Morgan has a patch up to replace blueprint usage with RFE bugs in the specification template [3]. We can air out any comments, questions, or concerns here in the thread. Thanks, Lance [0] https://blueprints.launchpad.net/keystone [1] http://specs.openstack.org/openstack/keystone-specs/ [2] https://etherpad.openstack.org/p/keystone-blueprint-cleanup [3] https://review.openstack.org/#/c/625282/

3 8

[TripleO] openvswitch is broken - avoid rechecks in the next couple hours
by Daniel Alvarez Sanchez 15 Feb '19

15 Feb '19

Hi folks, A new DPDK version landed in CentOS which is not compatible with the current Open vSwitch version that we have in RDO (error below). RDOfolks++ are working on it to make a new OVS version available without DPDK support so that we can unblock our jobs until we get a proper fix. Please, avoid rechecks in the next ~3 hours or so as no tests are expected to pass. Once [0] is merged, we'll need to wait around 30 more minutes for it to be available in CI jobs. Thanks! [0] https://review.rdoproject.org/r/#/c/18853 2019-02-14 07:35:06.464494 | primary | 2019-02-14 07:35:05 | Error: Package: 1:openvswitch-2.10.1-1.el7.x86_64 (delorean-master-deps) 2019-02-14 07:35:06.464603 | primary | 2019-02-14 07:35:05 | Requires: librte_table.so.3()(64bit) 2019-02-14 07:35:06.464711 | primary | 2019-02-14 07:35:05 | Available: dpdk-17.11-13.el7.x86_64 (quickstart-centos-extras)

6 7

[tc] dims non-nomination for TC
by Davanum Srinivas 15 Feb '19

15 Feb '19

Folks, I will not be running in the upcoming TC election. It's been a great experience being on the TC and working with all of you. I am / will be still around working on OpenStack related activities, so don't hesitate to ping me if you need need me. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims

2 1

Re: Why COA exam is being retired?
by Lauren Sell 15 Feb '19

15 Feb '19

Thanks very much for the feedback. When we launched the COA, the commercial market for OpenStack was much more crowded (read: fragmented), and the availability of individuals with OpenStack experience was more scarce. That indicated a need for a vendor neutral certification to test baseline OpenStack proficiency, and to help provide a target for training curriculum being developed by companies in the ecosystem. Three years on, the commercial ecosystem has become easier to navigate, and there are a few thousand professionals who have taken the COA and had on-the-job experience. As those conditions have changed, we've been trying to evaluate the best ways to use the Foundation's resources and time to support the current needs for education and certification. The COA in its current form is pretty resource intensive, because it’s a hands-on exam that runs in a virtual OpenStack environment. To maintain the exam (including keeping it current to OpenStack releases) would require a pretty significant investment in terms of time and money this year. From the data and demand we’re seeing, the COA did not seem to be a top priority compared to our investments in programs that push knowledge and training into the ecosystem like Upstream Institute, supporting OpenStack training partners, mentoring, and sponsoring internship programs like Outreachy and Google Summer of Code. That said, we’ve honestly been surprised by the response from training partners and the community as plans have been trickling out these past few weeks, and are open to discussing it. If there are people and companies who are willing to invest time and resources into a neutral certification exam, we could investigate alternative paths. It's very helpful to hear which education activities you find most valuable, and if you'd like to have a deeper discussion or volunteer to help, let me know and we can schedule a community call next week. Regardless of the future of the COA exam, we will of course continue to maintain the training marketplace at openstack.org to promote commercial training partners and certifications. There are also some great books and resources developed by community members listed alongside the community training. > From: Jay Bryant jungleboyj(a)gmail.com > Date: January 25, 2019 07:42:55 > Subject: Re: Why COA exam is being retired? > To: openstack-discuss(a)lists.openstack.org > >> On 1/25/2019 9:27 AM, Jonathan Proulx wrote: >>> On Fri, Jan 25, 2019 at 10:09:04AM -0500, Jay Pipes wrote: >>> :On 01/25/2019 09:09 AM, Erik McCormick wrote: >>> :> On Fri, Jan 25, 2019, 8:58 AM Jay Bryant <jungleboyj(a)gmail.com >>> >>> :> That's sad. I really appreciated having a non-vendory, ubiased, >>> :> community-driven option. >>> : >>> :+10 >>> : >>> :> If a vendor folds or moves on from Openstack, your certification >>> :> becomes worthless. Presumably, so long as there is Openstack, there >>> :> will be the foundation at its core. I hope they might reconsider. >>> : >>> :+100 >>> >>> So to clarify is the COA certifiaction going away or is the Foundation >>> just no longer administerign the exam? >>> >>> It would be a shame to loose a standard unbiased certification, but if >>> this is a transition away from directly providing the training and >>> only providing the exam specification that may be reasonable. >>> >>> -Jon >> >> When Allison e-mailed me last week they said they were having meetings >> to figure out how to go forward with the COA. The foundations partners >> were going to be offering the exam through September and they were >> working on communicating the status of things to the community. >> >> So, probably best to not jump to conclusions and wait for the official >> word from the community. >> >> - Jay > > >

1 2

[tc][all] Train Community Goals
by Lance Bragstad 15 Feb '19

15 Feb '19

Hi all, The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0]. During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes): 1. Moving legacy clients to python-openstackclient 2. Cleaning up resources when deleting a project 3. Service-side health checks I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here. Does anyone have strong opinions either way about the goals listed above? [0] https://etherpad.openstack.org/p/BER-t-series-goals

15 26

[kayobe] Kayobe 5.0.0 released
by Mark Goddard 15 Feb '19

15 Feb '19

Hi, I'm pleased to announce the release of Kayobe 5.0.0. This release supports deployment of OpenStack Rocky. Lots of new features and fixes, see [1]. Thanks to everyone who contributed. Now onto Stein - we're catching up! [1] https://kayobe-release-notes.readthedocs.io/en/latest/rocky.html Mark

1 0

[nova][dev] 3 weeks until feature freeze
by melanie witt 15 Feb '19

15 Feb '19

Howdy all, We've about 3 weeks left until feature freeze milestone s-3 on March 7: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule Non-client library freeze is in 2 weeks February 28, so if you need changes released in Stein for os-vif, os-traits, or os-resource-classes, they need to be merged by Feb 28 and the releases will be proposed on Feb 28. Ping us if you need review. I've updated the blueprint status tracking etherpad: https://etherpad.openstack.org/p/nova-stein-blueprint-status For our Cycle Themes: Multi-cell operational enhancements: The patch series for the API microversion for handling of down cells on the nova side has all been approved as of today. Only the python-novaclient change remains. Counting quota usage from placement is still an active WIP. Cross-cell resize is still making good progress with active code review. Compute nodes able to upgrade and exist with nested resource providers for multiple vGPU types: The libvirt driver reshaper patch has been updated today but needs some fixes for unit test failures. Volume-backed user experience and API improvement: The detach boot volume and volume-backed server rebuild patches are active WIP. If you are the owner of an approved blueprint, please: * Add the blueprint if I've missed it * Update the status if it is not accurate * If your blueprint is in the "Wayward changes" section, please upload and update patches as soon as you can, to allow maximum time for review * If your patches are noted as Merge Conflict or WIP or needing an update, please update them and update the status on the etherpad * Add a note under your blueprint if you're no longer able to work on it this cycle Let us know if you have any questions or need assistance with your blueprint. Cheers, -melanie

1 0

[cloudkitty] March IRC meeting is cancelled
by Luka Peschke 15 Feb '19

15 Feb '19

Hello everybody, Due to various people not being available on march 1st, the cloudkitty IRC meeting that was planned at that date is cancelled. The next meeting will be held on april 5th at 15h UTC / 17h CET. Cheers, -- Luka Peschke

1 0

[release][heat][tripleo][kolla][monsca] need PTL/liaison ACK on pending releases
by Doug Hellmann 15 Feb '19

15 Feb '19

We have a few pending releases that were proposed by someone who is not listed as the PTL or Liaison for the associated project. That's fine, but in those cases we need the PTL or Liaison to acknowledge and approve the release before we process it. Please take a minute today or Monday to look at these and indicate whether it is OK to release them. https://review.openstack.org/#/c/636285/ heat-translator 1.3.0 (stein) https://review.openstack.org/#/c/635569/ tripleo-heat-templates 8.3.0 (queens) https://review.openstack.org/#/c/635536/ kolla 6.1.1 (queens) https://review.openstack.org/#/c/637163/ python-monscaclient 1.13.0 (stein) -- Doug

3 3

Re: [requirements][requests] security update for requests in stable branches
by Matthew Thode 15 Feb '19

15 Feb '19

On 19-02-15 06:51:20, Boden Russell wrote: > Just to confirm; the best way to test with this change is to submit a > dummy patch that depends on 637124 in the respective project's > stable/rocky branch? > > > On 2/15/19 12:27 AM, Matthew Thode wrote: > > Recently it was reported to us that requests had a recent release that > > addressed a CVE (CVE-2018-18074). Requests has no stable branches so > > the only way to update openstack stable branches is to update to 2.20.1 > > in this case. I wanted to pass this by people as requests is generally > > a nasty library with nasty surprises. It's passed our cross and dvsm > > gating though (for rocky) so indications look good. What I'm asking you > > for is anything that could go wrong with updating (rocky in this case, > > but possibly back to newton, depending on co-installability). Please > > let me know any blockers to to update (in the review preferably). > > > > https://review.openstack.org/637124 > > > > Thanks, > > Yes -- Matthew Thode

1 0