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