Open Stack

On 9/27/2018 10:13 AM, Dean Troyer wrote:
> On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann<doug at doughellmann.com>  wrote:
>> Monty Taylor<mordred at inaugust.com>  writes:
>>> Main difference is making sure these new deconstructed plugin teams
>>> understand the client support lifecycle - which is that we don't drop
>>> support for old versions of services in OSC (or SDK). It's a shift from
>>> the support lifecycle and POV of python-*client, but it's important and
>>> we just need to all be on the same page.
>> That sounds like a reason to keep the governance of the libraries under
>> the client tool project.
> Hmmm... I think that may address a big chunk of my reservations about
> being able to maintain consistency and user experience in a fully
> split-OSC world.
> 
> dt

My biggest worry with splitting everything out into plugins with new 
core teams, even with python-openstackclient-core as a superset, is that 
those core teams will all start approving things that don't fit with the 
overall guidelines of how OSC commands should be written. I've had to go 
to the "Dean well" several times when reviewing osc-placement commands.

But the python-openstackclient-core team probably isn't going to scale 
to fit the need of all of these gaps that need closing from the various 
teams, either. So how does that get fixed? I've told Dean and Steve 
before that if they want me to review / ack something compute-specific 
in OSC that they can call on me, like a liaison. Maybe that's all we 
need to start? Because I've definitely disagreed with compute CLI 
changes in OSC that have a +2 from the core team because of a lack of 
understanding from both the contributor and the reviewers about what the 
compute API actually does, or how a microversion behaves. Or maybe we 
just do some kind of subteam thing where OSC core doesn't look at a 
change until the subteam has +1ed it. We have a similar concept in nova 
with virt driver subteams.

-- 

Thanks,

Matt