Hello :)

I think that these two goals definitely fit the criteria we discussed in
Vancouver during the S Release Goal Forum Session. I know Storyboard
Migration was also mentioned after I had to dip out to another session so I
wanted to follow up on that.

I know it doesn't fit the shiny user facing docket that was discussed at
the Forum, but I do think its time we make migration official in some
capacity as a release goal or some other way. Having migrated Ironic and
having TripleO on the schedule for migration (as requested during the last
goal discussion) in addition to having migrated Heat, Barbican and several
others in the last few months we have reached the point that I think
migration of the rest of the projects is attainable by the end of Stein.


-Kendall (diablo_rojo)

On Mon, Jun 4, 2018 at 11:08 AM 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.
> 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.
> 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

Reply via email to