- openstack-discuss - lists.openstack.org

[release] Release countdown for week R-4, March 11-15
by Sean McGinnis 07 Mar '19

07 Mar '19

We are getting close to the end of the cycle, so there are a lot of actions and deadlines to be aware of over the next few weeks. Please take a look through and let the release team know if here are any questions or concerns. Development Focus ----------------- The R-4 week is our one deadline free week between the Stein-3 milestone and RC. Work should be focused on fixing any requirements update issues, critical bugs, and wrapping up feature work to prepare for the Release Candidate deadline (for deliverables following the with-rc model) or final Stein releases (for deliverables following the with-intermediary model) on Thursday, 1st of April. General Information ------------------- For deliverables following the cycle-with-rc model, we are now (after the day I send this) past Feature Freeze. The focus should be on determining and fixing release-critical bugs. At this stage only bugfixes should be approved for merging in the master branches: feature work should only be considered if explicitly granted a Feature Freeze exception by the team PTL (after a public discussion on the mailing-list). StringFreeze is now in effect, in order to let the I18N team do the translation work in good conditions. The StringFreeze is currently soft (allowing exceptions as long as they are discussed on the mailing-list and deemed worth the effort). It will become a hard StringFreeze on March 21st along with the RC1. The requirements repository is also frozen, until all cycle-with-rc deliverables have produced a RC1 and have their stable/stein branches. If release critical library or client library releases are needed for Stein past the freeze dates, you must request a Feature Freeze Exception (FFE) from the requirements team before we can do a new release to avoid having something released in Rocky that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] FFE requested for $PROJECT_LIB Include justification/reasoning for why a FFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. Including a link to the FFE in the release request is not required, but would be helpful in making sure we are clear to do a new release. Actions --------- stable/stein branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update*. Please review those in priority so that the branch can be functional ASAP. * The constraints update patches should not be approved until a stable/stein branch has been created for openstack/requirements. Watch for an unfreeze announcement from the requirements team for this. For cycle-with-rc deliverables, release liaisons should wait until R-3 week to create RC1 (to avoid having an RC2 created quickly after). Review release notes for any missing information, and start preparing "prelude" release notes as summaries of the content of the release so that those are merged before the first release candidate. Along with the prelude work, it is also a good time to start planning what highlights you want for your project team in the cycle highlights: Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003597.ht… Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… diablo_rojo on IRC is available if you need help selecting or writing your highlights For release-independent deliverables, release liaisons should check that their deliverable file includes all the existing releases, so that they can be properly accounted for in the releases.openstack.org website. If your team has not done so, remember to file Stein goal completion information, as explained in: https://governance.openstack.org/tc/goals/index.html#completing-goals Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 21 Final RC deadline: April 1 Final Stein release: April 10 -- Sean McGinnis (smcginnis)

1 0

[tc][all][python3] Ad hoc meeting call for python 3 transition & planning for stein and train
by Ghanshyam Mann 07 Mar '19

07 Mar '19

Hello Everyone, During today TC meeting[1], we discussed to have an Ad hoc meeting regarding the python 3 transition and all pending tasks. Apart from below on-going tasks, what else to be done for either stein or train? There is doodle vote to select the time for the meeting[2], please mark your availability on that. Naser will be selecting the appropriate time within an hour or so. Current list of tasks for keeping up with python 3 releases ACTION: gmann raise the topic of porting legacy jobs to bionic on the mailing list ACTION: fungi propose a default node flag day to switch to ubuntu bionic ACTION: TheJulia investigate PTI updates for Train [1] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-03-07-14.04.log.htm… [2] https://doodle.com/poll/9dpc9zxek5mdsg8p -gmann

2 1

[release][PTL] Cycle Highlights Time!
by Kendall Nelson 07 Mar '19

07 Mar '19

Hello Everyone! Now that we are about at Stein-3 and our final RCs are fast approaching, I wanted to remind everyone about the 'cycle-highlights' you should add to your deliverable info. As PTLs you probably get many pings towards the end of every release cycle by various parties (marketing, management, journalists, etc) asking for highlights of what is new and what significant changes are coming in the new release. By putting them all in the same place it saves everyone a lot of time because they get compiled into a pretty website like this from Rocky[1], and then we can point all the curious parties to a single location. We don't need a fully fledged marketing message, just a few highlights (3-4 ideally), from each project team. How To Reminder: ------------------------- Simply add them to the deliverables/stein/$PROJECT.yaml in the openstack/releases repo similar to this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/stein/highlights.html file or the output of the build-openstack-sphinx-docs job under html/stein/ highlights.html. Thanks :) -Kendall Nelson (diablo_rojo) [1] https://releases.openstack.org/rocky/highlights.html

1 0

[nova] Reminders for Stein feature freeze
by Matt Riedemann 07 Mar '19

07 Mar '19

Today is feature freeze for Stein. osc-placement 1.5.0 has been released [1] and python-novaclient 13.0.0 should be released soon [2]. At this point I don't expect any last minute blueprints to be pushed through so any remaining blueprints will get deferred to Train and people can start re-proposing specs [3]. Having said that, Dan, Jay and I are working on trying to get at least the data model and migration change for counting quota usage from placement merged yet in Stein, which starts here [4]. The actual API code to use that will be deferred to Train but it would be good to get the data migration started in Stein to have fewer records to migrate in Train when the API starts relying on this data. There is no s-3 tag to be made for nova per the relatively recent change in how cycle-with-rc projects are released [5]. Remember that the Forum submission deadline is fast approaching (I am told it is March 10 now). Forum proposals for nova are here [6]. If you are thinking about submitting a forum session you should do it within the next 24 hours. You don't necessarily need to be in attendance either if someone else can chair your session to get feedback. RC1 for Stein is coming up in two weeks (March 21). The etherpad tracking TODOs for that is here [7]. In the next two weeks we need to be working on testing, daily bug triage [8], documentation (remember specs are generally a poor substitute for good in-tree feature documentation), and thinking about any nova-status upgrade checks we should add for Stein. [1] https://review.openstack.org/#/c/641531/ [2] https://review.openstack.org/#/c/641678/ [3] https://specs.openstack.org/openstack/nova-specs/readme.html#previously-app… [4] https://review.openstack.org/#/c/633349/ [5] https://releases.openstack.org/reference/release_models.html#cycle-with-rc [6] https://etherpad.openstack.org/p/DEN-train-nova-brainstorming [7] https://etherpad.openstack.org/p/nova-stein-rc-potential [8] https://tinyurl.com/y5degcvm -- Thanks, Matt

1 0

[ironic] Proposing two additions to ironic-core
by Julia Kreger 07 Mar '19

07 Mar '19

One of the hardest things I feel the need to do as a PTL is to send emails to inquire how core reviewers are doing when they have fallen silent or all signs point to they are distracted. It is nobody's fault, it is the nature of the work we do in the community. But those emails are still difficult for me to write, and truth be told I feel like an awful human being when I send them. But then there are times I can smile and send emails that hopefully will bring joy and happiness, such as this email! I'd like to propose to add the following individuals to ironic-core: Arne Wiebalck (arne_wieback) has been interacting with the ironic community for close to nine months and has become active in reviewing other contributors patches meanwhile collaborating with the community on new features. He also helps operate CERN's Bare Metal cloud and OpenStack deployment. While this may mean that sometimes he is busy with other things, he is able to provide direct operator feedback to the ironic community which is vital to ensure that we support and enable Bare Metal cloud operators. In reviewing the 120[0], 90[1], and 30[2] day statistics, Arne has consistently been in the top 10 reviewers. Riccardo Pittau (rpittau) is a relative newcomer to ironic, but has quickly taken to interacting with other contributors in code reviews, asking questions, and encouraging changes. His review statistics are also in the top 10 reviewers when looking at the 120[0], 90[1], and 30[2] day statistics, Riccardo has an operations background, which brings a great deal of value to the ironic community in the terms of real world experience with Bare Metal hardware. I believe both of these individuals would be excellent additions to the core reviewer team. Thoughts? Thanks, -Julia Note: Links are from Stackalytics. If anyone has independent reporting utilities that do not leverage stackalytics, please point me in the direction of such tools off-list. [0]: https://www.stackalytics.com/report/contribution/ironic-group/120 [1]: https://www.stackalytics.com/report/contribution/ironic-group/90 [2]: https://www.stackalytics.com/report/contribution/ironic-group/30

5 4

[tc][all] Call to review Train goal proposals
by Lance Bragstad 07 Mar '19

07 Mar '19

Hello everyone, As you might have seen, we have two community goals available for review. Adrian has proposed a goal [1] for cleaning up resources when deleting a project. Artem has a review up [2] detailing the legacy client work for Train. Your input would be very welcomed. This is an important step to improve OpenStack, and we hope those reviews will get the attention they deserve! Thank you, Lance & Jean-Philippe [1]: https://review.openstack.org/#/c/639010/ [2]: https://review.openstack.org/#/c/639376/

1 1

[tc] meeting agenda for 7 March 1400 UTC
by Doug Hellmann 07 Mar '19

07 Mar '19

TC Members, Our next meeting will be this Thursday, 7 Mar at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * TC election results Old business: * project team evaluations based on technical vision * defining the role of the TC * keeping up with python 3 releases * Train cycle goals selection update * new chair for train New business: #topic OIP review process -- Doug

1 2

[I18n] PTL Non-Candidacy
by Frank Kloeker 07 Mar '19

07 Mar '19

Hello, following the release calendar PTL self-nomination starts today and I would like to announce my non-candidacy for the Train cycle. We reached a lot in the last three cycles: - Continous translation of OpenStack core projects - Translating whitepapers and User Survey for OSF - Setup translation check server and extend functionality - Start project doc translation We had a great time last year during Berlin Summit in Germany. Now it's up to rotate PTL role as it's thought to get fresh air in the project. I'm still part of the community and available for help as I18n and Docs core. But I also want to do something with research in AI/Machine Translation, to find useful use cases in the project. I would like to thank everyone who supported me over the years. It was a great experience and I can recommend it for everyone :) kind regards Frank

6 6

[ptl][keystone][election] PTL Candidacy
by Colleen Murphy 07 Mar '19

07 Mar '19

Please consider my candidacy for the role of keystone PTL. I have been involved with keystone for a little over three years and have loved it from the beginning. My first introduction to keystone was from the perspective of a deployer project contributor, while I was working on getting the Puppet-OpenStack modules to work with the keystone v3 API. I found the problem space fascinating and the people warm and welcoming. Given free reign at the time to work on anything that interested me, I chose to jump into keystone. I currently work at SUSE as a cloud engineer specializing in the keystone component. I see keystone as being in a unique position in the OpenStack ecosystem as a sort of backbone of OpenStack. As such, the challenges we face as a team are somewhat self-imposed: we don't have vendors pressuring us to get features in, but rather we push ourselves to add features to make OpenStack as a whole better. Deficiencies in keystone means hardship for nearly all OpenStack operators and difficulties for other OpenStack developers. It's a tough burden to bear and yet it's what makes keystone the most fun to work on. As PTL, my top technical focus will be in continuing the great work Lance has done around improving the policy and RBAC experience for operators, and helping to drive the changes needed in the rest of the OpenStack to fulfill this long-overdue goal. We will work to envision and fulfill the TC's technical vision for OpenStack[1][2], striving for true multitenancy and enabling a completely self-service solution. Aside from that, I will not plan to drive many features. Instead I will work to empower other developers to drive feature work and grow into maintainers, by taking a step back to clean up technical debt, fix longstanding bugs, and enhance our CI test coverage and performance measuring. I will invest heavily in our contributor documentation, digging up and writing down the team's tribal knowledge, and I'd like to start building out and documenting reference architectures for keystone in conjunction with operators and working groups. As a team, we need to continue to encourage and recruit new contributors and grow them into the core team. We do that by continuing to participate in mentoring programs like Outreachy or in university capstone classes, by reaching out to users and operators and helping them contribute back, by creating bite-sized chunks of work that a new person can tackle quickly (Lance did a great job of this by breaking up the system scope and reader role work into separate tasks), and by continuing to be ourselves: friendly and welcoming, non-nitpicky, helpful and responsive. In the last few months we've already seen a pickup in long-term maintainers and it's been a welcome sight. I want to thank Lance for doing an amazing job as PTL for the last few years and for everything he's accomplished, and I can only hope to live up to the example he's set. Thank you for your consideration. Colleen Murphy (cmurphy) [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] https://review.openstack.org/641374

1 0

[kolla] PTL Non-Candidacy
by Eduardo Gonzalez 07 Mar '19

07 Mar '19

Hello, This email is to announce my non candidacy for being PTL for the Train cycle. Has been an honor to serve in the Stein cycle and I'll definitively still be in the community whiling to help anyone who needs it. Best luck for the future candidates. Regards

4 3