Open Stack

For Octavia, implementing an OSC plugin has worked out exceptionally
well. I have also got good feedback from users that OSC is much better
than the legacy clients in functionality and ease of use.

That said, I have spent some quality time with Dean (thank you again)
making sure we didn't stray from the OSC vision.

I think like any other guideline or standard in OpenStack we just need
to focus on documenting those guidelines and standards well (there are
already pretty good documents for this, thank you again to the OSC
team). Then it is up to us to pay attention to them and correct our
mistakes when we make them.

Personally I think all projects should be implemented as plugins. This
makes it "obvious" to users when they need a service functionality
they need to install the correct plugin. Currently we get "Why doesn't
the client support Octavia?" questions when we were one of the early
plugins. This also has the advantage of limiting the footprint of the
client install for deployments that don't need all of the services.
For example, I don't need object nor block storage. It would be nice
to not use the disk and tab completion space for those. One of the
nice things about the project team owning the plugin is you don't get
rogue patches merging that don't align to the project team vision ('-'
vs. "_" anyone?).

Michael

On Fri, Aug 23, 2019 at 1:38 PM Matt Riedemann <mriedemos at gmail.com> wrote:
>
> 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
>