Open Stack

+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