[Openstack-operators] [openstack-dev] [TC] Stein Goal Selection
sean.mcginnis at gmx.com
Mon Jun 4 22:19:55 UTC 2018
Adding back the openstack-operators list that Matt added.
On 06/04/2018 05:13 PM, Sean McGinnis wrote:
> 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
>>>> excitement and are obvious benefits to deployers and users of
>>>> 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
>>>> everywhere, with our Python 2 compatibility being just to continue
>>> 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
>> 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
>>>> 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.
> 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:
>>> 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
>>> 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.
>> 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
>>>> 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
>>> 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
>>> 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.
>> 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.
> 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.
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-operators