- openstack-discuss - lists.openstack.org

[User-committee] UC Candidacy
by Belmiro Moreira 18 Feb '19

18 Feb '19

Greetings, I'd like to announce my candidacy for the OpenStack User Committee (UC). I'm involved with OpenStack since 2011 when CERN started to investigate a Cloud Infrastructure solution. I work in the design/deployment/operation of the CERN OpenStack Cloud (from 0 to +300k cores). My particular interest has been how to scale and operate large OpenStack deployments. I was an active member of the Large Deployment Team (LDT), a group of operators that shared ideas on how to scale OpenStack. I had the privilege to learn from a talented group of Operators on how they manage/run their infrastructures. I'm fortunate enough to have attended all OpenStack Summits since San Francisco (2012). I'm a regular speaker talking about my experience operating OpenStack at scale. Also, I serve regularly as a track chair, participated in few OpenStack Days, Ops Meetups and wrote several blog posts. I believe that the Operators/User community should have an active role in the design of the next features for the OpenStack/Open Infrastructure projects. If elected I will focus to engage the Operator/Users community with the different Development teams. It would be an honor to be an advocate of this great community and promote its mission. Thank you for your consideration, Belmiro Moreira

2 1

[all][tc] Formalizing cross-project pop-up teams
by Thierry Carrez 17 Feb '19

17 Feb '19

TL;DR: Maybe to help with cross-project work we should formalize temporary teams with clear objective and disband criteria, under the model of Kubernetes "working groups". Long version: Work in OpenStack is organized around project teams, who each own a set of git repositories. One well-known drawback of this organization is that it makes cross-project work harder, as someone has to coordinate activities that ultimately affects multiple project teams. We tried various ways to facilitate cross-project work in the past. It started with a top-level repository of cross-project specs, a formal effort which failed due to a disconnect between the spec approvers (TC), the people signed up to push the work, and the teams that would need to approve the independent work items. This was replaced by more informal "champions", doing project-management and other heavy lifting to get things done cross-project. This proved successful, but champions are often facing an up-hill battle and often suffer from lack of visibility / blessing / validation. SIGs are another construct that helps holding discussions and coordinating work around OpenStack problem spaces, beyond specific project teams. Those are great as a permanent structure, but sometimes struggle to translate into specific development work, and are a bit heavy-weight just to coordinate a given set of work items. Community goals fill the gap between champions and SIGs by blessing a given set of cross-community goals for a given release. However, given their nature (being blessed by the TC at every cycle), they are a better fit for small, cycle-long objectives that affect most of the OpenStack project teams, and great to push consistency across all projects. It feels like we are missing a way to formally describe a short-term, cross-project objective that only affects a number of teams, is not tied to a specific cycle, and organize work around a temporary team specifically formed to reach that objective. A team that would get support from the various affected project teams, increasing chances of success. Kubernetes encountered the same problem, with work organized around owners and permanent SIGs. They created the concept of a "working group"[1] with a clear limited objective, and a clear disband criteria. I feel like adopting something like it in OpenStack could help with work that affects multiple projects. We would not name it "working group" since that's already overloaded in OpenStack, but maybe "pop-up team" to stress the temporary nature of it. We've been sort-of informally using those in the past, but maybe formalizing and listing them could help getting extra visibility and prioritization. Thoughts? Alternate solutions? [1] https://github.com/kubernetes/community/blob/master/committee-steering/gove… -- Thierry Carrez (ttx)

11 23

[Tacker][Searchlight] Implementing Tacker plugin for Searchlight
by Trinh Nguyen 16 Feb '19

16 Feb '19

Hi Tacker team, The Searchlight team is trying to implement a Tacker plugin for Searchlight that has two features: - Index Tacker resource info & events into ElasticSearch - Create an event trigger engine to provide self-healing if needed There's nothing needed to be changed at the Tacker side but it would be great if you guys can help to suggest what resource info we should get and where we can get those. The proposed spec of the feature is here [1]. My initial plan is to use the tacker client to list the resources and the oslo_messeging bus to get the events/notifications. [1] https://review.openstack.org/#/c/636856/ Any concerns or questions let me know. Many thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

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

16 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 16 Feb '19

16 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 16 Feb '19

16 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 16 Feb '19

16 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 16 Feb '19

16 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 16 Feb '19

16 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 16 Feb '19

16 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