Open Stack

On 8/23/2019 9:59 AM, Graham Hayes wrote:
>  From what I have heard, some of the problems with relying on OSC was
> reliance on a central (OSC) team for implementation and reviews.

Yes, that's true, it's basically Dean doing core reviews these days it 
seems.

> 
> Would moving tools like cinder or glance to OSC plugins help solve
> some of these concerns? This would allow the teams to control the CLI
> destiny, and even allow teams to add features to team CLIs and OSC
> simultaneously, while (or if) we transition to OSC.

This came up at one of the Denver PTGs with Dean in the nova room. The 
upside is project teams could move things themselves faster, like they 
do with their own python-*client projects today. They are also the ones 
that know better how their API works. Nova did this with the 
osc-placement plugin but still ask Dean for UX guidance from time to time.

The downside of project teams owning their parts of the CLI are losing a 
unified vision for how the commands should be structured which is really 
one of the main reasons for OSC in the first place, a unified, 
standardized and good user experience, rather than all of the different 
little things that each project team did in their CLI. So if we did let 
project teams own their parts of OSC (I know some already do - 
placement, ironic, designate, watcher, etc), we would have to trust them 
to follow whatever guidelines exist since Dean can't be herding all 
those cats.

Honestly I don't really trust (real surprise here right folks?!) most 
developers (myself included), left alone, to do things the "OSC way" 
unless they already have some experience with working on OSC - or at 
least communicating with Dean for UX questions. Based on that, I'd 
prefer that at least "core" component CLIs remain within OSC and the 
purview of that core team. But the core team problem needs to be solved 
which would mean expanding the OSC core team. We definitely need more 
'core' project cores (nova/cinder/glance/keystone/neutron) reviewing 
changes to OSC for their components and maybe that's the path to 
becoming a core on OSC, if the whole sub-domain core thing works there, 
I don't know (I'm not on the OSC core team). I would still want Dean 
overseeing things happening at the component level though, at least 
until there are more obvious OSC-wide cores, i.e. component core(s) 
+1/+2 a thing but Dean has final say.

Anyway, that's my 2 cents.

-- 

Thanks,

Matt