Open Stack

On 06/04/2018 04:17 PM, Doug Hellmann wrote:
> Excerpts from Matt Riedemann's message of 2018-06-04 15:38:48 -0500:
>> 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.
> We still run docs, linters, functional tests, and other jobs under
> python 2 by default. Perhaps a better framing would be to call this
> "Python 3 by default", because the point is to change all of those jobs
> to use Python 3, and to set up all future jobs using Python 3 unless we
> specifically need to run them under Python 2.
>
> This seems like a small thing, but when we did it for Oslo we did find
> code issues because the linters apply different rules and we did find
> documentation build issues. The fixes were all straightforward, so I
> don't expect it to mean a lot of work, but it's more than a single patch
> per project. I also think using a goal is a good way to start shifting
> the mindset of the contributor base into this new perspective.
Yes, that's probably a better way to word it to properly convey the goal.
Basically, all things running under Python3, project code and tooling, as
the default unless specifically geared towards Python2.

>>> 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.
Not so much mixing as discussing the two and the reason why I personally 
thought
the one was a better goal, if you read through what was said about it.
>>
>> 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.
> What I remember from the discussion in the room was that not all
> projects are going to have anything to do by hand that would block
> an upgrade, but we still want all projects to have the test command.
> That means many of those commands could potentially be no-ops,
> right? Unless they're all going to do something like verify the
> schema has been updated somehow?

Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would
check here. We don't have to see if placement has been set up or if cell0
has been configured. Maybe once we have the facility in place we would
find some things worth checking, but at present I don't know what that
would be.

Which also makes me wonder, should this be an oslo thing that projects
just plug in to for their specific checks?

>>> 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.
> I support this one, too. We're going to need more contributors
> working on the CLI team, I think, to make it happen, though. Dean
> is way over his capacity, I'm basically not present, and we've lost
> Steve. That leaves Akihiro and Rui to do most of the review work,
> which isn't enough.
>
> Doug
I was tempted to go with the OSC one too, but I was afraid resource
constraints would make that unlikely. I haven't checked lately, but
last I heard neither Cinder v3 nor microversions were supported yet.

Maybe this has changed, but my impression is that a lot of work needs
to be done before we can reasonably expect this to be a goal that we
have a chance of getting near completion in a cycle.