- openstack-discuss - lists.openstack.org

openstack-dev@lists.openstack.org bounces
by Fox, Kevin M 24 Mar '19

24 Mar '19

Is it time to setup openstack-dev(a)lists.openstack.org to bounce emails rather then send them to a list where the community isn't listening anymore on? I still see folks use it occasionally by mistake. Thanks, Kevin

2 2

[dev][keystone] Keystone Team Update - Week of 18 March 2019
by Colleen Murphy 23 Mar '19

23 Mar '19

# Keystone Team Update - Week of 18 March 2019 ## News ### Release Candidates We released our Stein RC1 this week[1]! Please test it and report any issues ASAP. We've concluded that we'll be going for an RC2. I've tagged bugs that are either fairly critical or close to done for RC2[2]. We're also tracking patches we want to have merged for RC2[3]. We can submit a new release candidate proposal either when those are closed and merged or in time for the final release deadline[4], whichever comes first. There is also now a stable/stein branch, so please remember that all changes that are intended for RC2 need to be backported to stable/stein. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004093.ht… [2] https://launchpad.net/keystone/+milestone/stein-rc2 [3] https://etherpad.openstack.org/p/keystone-stein-rc2-tracking [4] https://releases.openstack.org/stein/schedule.html#s-finalrc ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 35 changes this week, including some important Python3 fixes, some system scope updates and several Rocky backports. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 47 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. Please give particular attention to the reviews that are fixing RC bugs or implementing system scope/default roles functionality. ## Bugs This week we opened 1 new bugs and closed 4. Bugs opened (1) Bug #1820367 (keystone:Undecided) opened by srinig81 https://bugs.launchpad.net/keystone/+bug/1820367 Bugs closed (1) Bug #1820367 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1820367 Bugs fixed (3) Bug #1750660 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1750660 Bug #1819036 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1819036 Bug #1820333 (keystone:High) fixed by Corey Bryant https://bugs.launchpad.net/keystone/+bug/1820333 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html The final RC is due in two weeks and the Stein release will follow that. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

Re: [openstack-dev] [nova] Volunteer needed to write reshaper FFU hook
by Eric Fried 23 Mar '19

23 Mar '19

Is it time to resurrect this now that we're getting close to having a release which reshapes when you upgrade to it? Eric Fried > On Oct 29, 2018, at 22:29, Zhenyu Zheng <zhengzhenyulixi(a)gmail.com> wrote: > > I would like to help since I have now finished all the downstream works. But I may need to take some time understanding all the background information > >> On Mon, Oct 29, 2018 at 11:25 PM Matt Riedemann <mriedemos(a)gmail.com> wrote: >> Given the outstanding results of my recruiting job last week [1] I have >> been tasked with recruiting one of our glorious and most talented >> contributors to work on the fast-forward-upgrade script changes needed >> for the reshape-provider-tree blueprint. >> >> The work item is nicely detailed in the spec [2]. A few things to keep >> in mind: >> >> 1. There are currently no virt drivers which run the reshape routine. >> However, patches are up for review for libvirt [3] and xen [4]. There >> are also functional tests which exercise the ResourceTracker code with a >> faked out virt driver interface to test reshaping [5]. >> >> 2. The FFU entry point will mimic the reshape routine that will happen >> on nova-compute service startup in the ResourceTracker [6]. >> >> 3. The FFU script will need to run per-compute service rather than >> globally (or per cell) since it actually needs to call the virt driver's >> update_provider_tree() interface which might need to inspect the >> hardware (like for GPUs). >> >> Given there is already a model to follow from the ResourceTracker this >> should not be too hard, the work will likely mostly be writing tests. >> >> What do you get if you volunteer? The usual: fame, fortune, the respect >> of your peers, etc. >> >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2018-October/136075.html >> [2] >> https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/resha… >> [3] https://review.openstack.org/#/c/599208/ >> [4] https://review.openstack.org/#/c/521041/ >> [5] >> https://github.com/openstack/nova/blob/a0eacbf7f/nova/tests/functional/test… >> [6] >> https://github.com/openstack/nova/blob/a0eacbf7f/nova/compute/resource_trac… >> >> -- >> >> Thanks, >> >> Matt >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

[dev][ptl][tempest-plugins][release] Reminder to release Tempest-plugins for stein if not done yet
by Ghanshyam Mann 22 Mar '19

22 Mar '19

Hello Everyone, you might have seen the release countdown email from Sean[1]. All tempest-plugins follow 'cycle-with-intermediary' release model and if you have not done the release for your tempest-plugin for stein, or want to do final release, it's time to push the release before Monday (25th). NOTE: you do not need to cut the stable/stein in the release as tempest-plugins are branchless. In case of any query, ping me or release team or follow these example - https://review.openstack.org/#/c/645399/ - https://review.openstack.org/#/c/645237/ [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004100.ht… -gmann

1 0

mistral-extra 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 22 Mar '19

22 Mar '19

Hello everyone, A new release candidate for mistral-extra for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral-extra/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/mistral-extra/log/?h=stable/stein Release notes for mistral-extra can be found at: https://docs.openstack.org/releasenotes/mistral-extra/

1 0

mistral 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 22 Mar '19

22 Mar '19

Hello everyone, A new release candidate for mistral for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/mistral/log/?h=stable/stein Release notes for mistral can be found at: https://docs.openstack.org/releasenotes/mistral/

1 0

mistral-dashboard 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 22 Mar '19

22 Mar '19

Hello everyone, A new release candidate for mistral-dashboard for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/mistral-dashboard/log/?h=stable/st… Release notes for mistral-dashboard can be found at: https://docs.openstack.org/releasenotes/mistral-dashboard/

1 0

storlets 3.0.0.0rc1 (stein)
by no-reply＠openstack.org 22 Mar '19

22 Mar '19

Hello everyone, A new release candidate for storlets for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/storlets/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/storlets/log/?h=stable/stein Release notes for storlets can be found at: https://docs.openstack.org/releasenotes/storlets/

1 0

Re: networking-powervm 8.0.0.0rc1 (stein)
by James LaBarre 22 Mar '19

22 Mar '19

On 3/21/19 1:39 PM, no-reply(a)openstack.org wrote: > Hello everyone, > > A new release candidate for networking-powervm for the end of the Stein > cycle is available! You can find the source code tarball at: > > ... > Release notes for networking-powervm can be found at: > > https://docs.openstack.org/releasenotes/networking-powervm/ Just FYI, the links for this and the ceilometer-powervm release nodes don't work.

2 1

[tc][infra] When a project leaves OpenStack
by Jeremy Stanley 22 Mar '19

22 Mar '19

This is a discussion I've been meaning to start for a very, very long while. The tl;dr of it is that when official OpenStack projects have ceased to meet our expectations for what it means to be OpenStack, allowing them to continue on in an unofficial capacity but otherwise unchanged has led to confusion among users. Finding a better way to handle project removals is my goal for this conversation. Inevitably, there are times when projects cannot continue to be a part of OpenStack. Often this is because development has ceased, and so we can retire their repositories cleanly leaving a notice to any remaining users that the project is unmaintained. Sometimes a project is unable or unwilling to continue to be a part of OpenStack officially, and we have made the choice to simply remove them from our governance but otherwise wish them well on their new journey. Unfortunately, more often than not, a formerly official project continuing development outside OpenStack is an indication it's nearing the end of its life, soon thereafter ceasing development and leaving behind an abandoned repository where even the most critical bugs go untriaged and proposed fixes unreviewed. This is the case for a lot of software which has ceased viability, so unsurprising, but given it was once a part of OpenStack there are users who simply assume it's still maintained and so it reflects negatively on us when they end up having a bad experience. One possibility we've entertained, over the years this topic has cropped up, is to declare that projects in the infrastructure we share (soon to be known as OpenDev) which were once an official part of OpenStack retain some residual TC jurisdiction so that if we notice their maintainers have disappeared we can take over and close down the project more thoroughly. This may work well enough in situations where it's brought to our attention, but will clearly not help the first people to notice this situation nor does it help in cases where we're never informed. With the "namespace explosion" coming in OpenDev, however, there's another option open to us. We could require that any development which continues after removal from OpenStack be done as a fork of the original. In theory we could have done that even with one common namespace, by requiring projects to either cease using this infrastructure entirely or change their name. Neither of these options is especially desirable. Now, however, we might consider allowing them to continue in the same infrastructure under the same repository name but in a different namespace. We would effectively close down development on the original repository following our normal retirement process, but could optionally also include a note mentioning where continued development is known to be taking place instead. Does anyone have other ideas to suggest? -- Jeremy Stanley

3 3