[all] [tc] [osc] [glance] [train] [ptls] Legacy client CLI to OSC review 639376
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
> 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
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.