Open Stack

Hi Sean,

These goals look reasonable for me.

On Mon, Jun 4, 2018 at 9:07 PM, Sean McGinnis <sean.mcginnis at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180604/26be11d4/attachment-0001.html>