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