Open Stack

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 
>>>> 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.
>
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev