Hi Sean, These goals look reasonable for me.
On Mon, Jun 4, 2018 at 9:07 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote: > Hi everyone, > > This is to continue the discussion of the goal selection for the Stein > release. > I had previously sent out a recap of our discussion at the Forum here: > > http://lists.openstack.org/pipermail/openstack-dev/2018-May/130999.html > > Now we need to actually narrow things down and pick a couple goals. > > Strawman > ======== > > Just to set a starting point for debate, I propose the following two as > goals > for Stein: > > - Cold Upgade Support > - Python 3 first > > As a reminder of other ideas, here is the link to the backlog of goal ideas > we've kept so far: > > https://etherpad.openstack.org/p/community-goals > > Feel free to add more to that list, and if you have been involved in any > of the > things that have been completed there, please remove things you don't think > should still be there. > > This is by no means an exhaustive list of what we could or should do for > goals. > > With that, I'll go over the choices that I've proposed for the strawman. > > Python 3 First > ============== > > One of the things brought up in the session was picking things that bring > excitement and are obvious benefits to deployers and users of OpenStack > services. While this one is maybe not as immediately obvious, I think this > is something that will end up helping deployers and also falls into the > tech > debt reduction category that will help us move quicker long term. > > Python 2 is going away soon, so I think we need something to help compel > folks > to work on making sure we are ready to transition. This will also be a good > point to help switch the mindset over to Python 3 being the default used > everywhere, with our Python 2 compatibility being just to continue legacy > support. > I hope we'll have Ubuntu 18.04 LTS on our gates for this activity soon. It becomes important not only for developers but for operators and vendors too. > Cold Upgrade Support > ==================== > > The other suggestion in the Forum session related to upgrades was the > addition > of "upgrade check" CLIs for each project, and I was tempted to suggest > that as > my second strawman choice. For some projects that would be a very minimal > or > NOOP check, so it would probably be easy to complete the goal. But > ultimately > what I think would bring the most value would be the work on supporting > cold > upgrade, even if it will be more of a stretch for some projects to > accomplish. > > Upgrades have been a major focus of discussion lately, especially as our > operators have been trying to get closer to the latest work upstream. This > has > been an ongoing challenge. > > A big +1 from my side on it. There has also been a lot of talk about LTS releases. We've landed on fast > forward upgrade to get between several releases, but I think improving > upgrades > eases the way both for easier and more frequent upgrades and also getting > to > the point some day where maybe we can think about upgrading over several > releases to be able to do something like an LTS to LTS upgrade. > > Neither one of these upgrade goals really has a clearly defined plan that > projects can pick up now and start working on, but I think with those > involved > in these areas we should be able to come up with a perscriptive plan for > projects to follow. > > And it would really move our fast forward upgrade story forward. > > Next Steps > ========== > > I'm hoping with a strawman proposal we have a basis for debating the > merits of > these and getting closer to being able to officially select Stein goals. We > still have some time, but I would like to avoid making late-cycle > selections so > teams can start planning ahead for what will need to be done in Stein. > > Please feel free to promote other ideas for goals. That would be a good > way for > us to weigh the pro's and con's between these and whatever else you have in > mind. Then hopefully we can come to some consensus and work towards clearly > defining what needs to be done and getting things well documented for > teams to > pick up as soon as they wrap up Rocky (or sooner). > > --- > Sean (smcginnis) > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
