- openstack-discuss - lists.openstack.org

[ptl][loci][election]
by Chris Hoge 08 Mar '19

08 Mar '19

I am announcing my candidacy for Loci PTL. I stepped in as interim PTL during the previous cycle and was a member of the founding core team. Loci is a project for packaging OpenStack projects into lightweight Docker images. It's currently being used in OpenStack-Helm and StarlingX. We have a small team, a stable project, and low velocity, but still have a number of objectives to work towards in the next cycle. My agenda as PTL will include: * Adopting stable branches. There are enough recent dependency changes that require us to reevaulate our stance on stable branching. * Improving testing. Currently the only thing Loci tests are builds without any functional or integration testing. We will look at ways to run project tests and Tempest integrated tests against a small single node deployment[1] of OpenStack with Loci. I will also continue to encourage adoption of Loci and support use cases in container-based OpenStack deployments. Thank you for support, and if elected I look forward to representing the Loci team and the OpenStack community in the coming months. -Chris Hoge (hogepodge) [1] this, for example https://github.com/hogepodge/locistack

1 0

Looking for proposed Forum sessions?
by Matt Riedemann 08 Mar '19

08 Mar '19

The deadline is fast approaching so if you're waiting for someone to submit a Forum session for something but are not sure if there is already one out there, you can search here: https://www.openstack.org/summit/denver-2019/vote-for-speakers#/23563 -- Thanks, Matt

1 0

[all][qa] tempest-multinode-full and tempest-slow job will start running on stable/* branches
by Ghanshyam Mann 08 Mar '19

08 Mar '19

Hi All, Till now Tempest jobs 'tempest-multinode-full' & 'tempest-slow' are running on master gate only because those are restricted by branch variant to mater-only[1]. Those jobs are supposed to be run for stable branches also. Many projects (for example Nova) have added them in their stable branch gate pipeline to test the backport changes. Below two patches are removing the master branch restriction from them so that they will run on stable branches also. Stable/pike and stable/queens were failing due to ssh issue which is fixed and merged in both branches. Both jobs are running fine now on all stable branches, I have tested them on Nova stable branches gate[2] - https://review.openstack.org/#/c/610938/ - https://review.openstack.org/#/c/620582/ I have opened the above two patches to merge now. tempest-slow job is voting in stable branch and tempest-multinode-full is non voting in most of the places. so once above two patches are merged, below are the change will happen in stable branch gate testing: 1. stable gate will start running the tempest-slow and tempest-multinode-full job where ever it is already added in stable branch pipeline. 2. If any of your job derived from either tempest-slow or tempest-multinode-full job and not supposed to run for stable branch (and till now it relies on master restriction of base job) then, you need to handle the same restriction in your job. 3. If you are looking for multinode/slow test coverage in stable branches then, they are available now. Feel free to ping me on IRC or via this mail thread for anything or if we need to wait for those patches to get merge (in case any projects is affected) [1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n202 http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n267 [2] https://review.openstack.org/#/q/topic:tempest-multinode-slow-stable+(statu… -gmann

1 1

[tc] welcoming Mohammed Naser as our new TC chair for Train
by Doug Hellmann 08 Mar '19

08 Mar '19

Everyone, As I mentioned in a previous email, I decided to step down as TC chair this cycle. Mohammed Naser has volunteered to serve as chair for the Train cycle, and was confirmed by the committee during our meeting today [1]. We have one or two more bookkeeping items to take care of in the transition, but agreed that Mohammed would start serving as chair right away. Thank you, Mohammed, for volunteering. I wish I knew where you found the time to do all that you do for our community! -- Doug [1] https://review.openstack.org/#/c/641405/

4 3

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

08 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 08 Mar '19

08 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 08 Mar '19

08 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 08 Mar '19

08 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 08 Mar '19

08 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 08 Mar '19

08 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