[Openstack-operators] [openstack-dev] [TC] Stein Goal Selection
mriedemos at gmail.com
Mon Jun 4 20:41:17 UTC 2018
+openstack-operators since we need to have more operator feedback in our
community-wide goals decisions.
+Melvin as my elected user committee person for the same reasons as
adding operators into the discussion.
On 6/4/2018 3:38 PM, Matt Riedemann wrote:
> On 6/4/2018 1:07 PM, Sean McGinnis wrote:
>> 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
>> 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
>> 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
> I still don't really know what this goal means - we have python 3
> support across the projects for the most part don't we? Based on that,
> this doesn't seem like much to take an entire "goal slot" for the release.
>> Cold Upgrade Support
>> The other suggestion in the Forum session related to upgrades was the
>> 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
>> 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
> I think you might be mixing two concepts here.
> The cold upgrade support, per my understanding, is about getting the
> assert:supports-upgrade tag:
> Which to me basically means the project runs a grenade job. There was
> discussion in the room about grenade not being a great tool for all
> projects, but no one is working on a replacement for that, so I don't
> think it's really justification at this point for *not* making it a goal.
> The "upgrade check" CLIs is a different thing though, which is more
> about automating as much of the upgrade release notes as possible. See
> the nova docs for examples on how we have used it:
> I'm not sure what projects you had in mind when you said, "For some
> projects that would be a very minimal or NOOP check, so it would
> probably be easy to complete the goal." I would expect that projects
> aren't meeting the goal if they are noop'ing everything. But what can be
> automated like this isn't necessarily black and white either.
>> 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
>> forward upgrade to get between several releases, but I think improving
>> 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
>> 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.
> Agreed. In the FFU Forum session at the summit I mentioned the
> 'nova-status upgrade check' CLI and a lot of people in the room had
> never heard of it because they are still on Mitaka before we added that
> CLI (new in Ocata). But they sounded really interested in it and said
> they wished other projects were doing that to help ease upgrades so they
> won't be stuck on older unmaintained releases for so long. So anything
> we can do to improve upgrades, including our testing for them, will help
> make FFU better.
>> 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
>> 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).
> I still want to lobby for a push to move off the old per-project CLIs
> and close the gap on using python-openstackclient CLI for everything,
> but I'm unclear on what the roadmap is for the major refactor with the
> SDK Monty was talking about in Vancouver. From a new user perspective,
> the 2000 individual CLIs to get anything done in OpenStack has to be a
> major turn off so we should make this a higher priority - including
> modernizing our per-project documentation to give OSC examples instead
> of per-project (e.g. nova boot) examples.
More information about the OpenStack-operators