+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
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 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
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.
I think you might be mixing two concepts here.
The cold upgrade support, per my understanding, is about getting the
assert:supports-upgrade tag:
https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html
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:
https://docs.openstack.org/nova/latest/cli/nova-status.html
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
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.
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
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).
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.
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
