Open Stack

On Thu, 2019-05-30 at 03:51 +0000, Nadathur, Sundar wrote:
> > From: Dean Troyer <dtroyer at gmail.com>
> > Sent: Thursday, May 23, 2019 1:23 PM
> > Subject: Re: [cyborg][nova][sdk]Cyborgclient integration
> > 
> > On Thu, May 23, 2019 at 1:03 PM Nadathur, Sundar
> > <sundar.nadathur at intel.com> wrote:
> > > IIUC, the push towards OpenStack SDK [4] is unrelated to OpenStack CLI. It
> > 
> > becomes relevant only if some other service wants to call into Cyborg.
> > 
> > Yes and no.  The two things are generally independent, however they will
> > eventually fit together in that we want OSC to use the SDK for all back-end
> > work soon(TM), depending on when we get an SDK 1.0 release.
> > 
> > At the 2018 Denver PTG we started thinking about what OSC plugins that use
> > the SDK would look like, and the only things left in the plugin itself would be
> > the cliff command classes.  Since SDK is accepting direct support for official
> > projects directly in the repo, OSC will consider doing the same for commands
> > that do not require any additional dependencies, ie if Cyborg were completely
> > backed by the SDK we would consider adding its commands directly to the
> > OSC repo.
> 
> We do intend to adopt the SDK.
> 
> > This is a significant change for OSC, and would come with one really large
> > caveat: commands must maintain the same level of consistency that the rest
> > of the commands in the OSC repo maintain.  ie, 'update'
> > is not a verb, resources do not contain hyphens in their names, etc.
> > There are projects that have deviated from these rules in their plugins, and
> > there they are free to do that, incurring only the wrath or disdain or joy of
> > their users for being different.  That is not the case for commands contained
> > in the OSC repo itself.
> 
> We are trying to understand the pros and cons of doing the OSC plugin vs integrating directly into OSC repo. 
> 
> 1. Consistency requirements are fine. Presumably we should follow [1]. They seem to be loose guidelines than specific
> requirements. I suppose the command syntax would look like:
>     $ openstack accelerator create device-profile <args>
i think this should be "openstack acclerator device-profile create" looking how
"security group rule create" works the action is always last in the osc commands
> 
> 2. When you say, " This is a significant change for OSC ", could you tell us what the risks are for direct
> integration? The repo [2] seems to have entries for compute, network, identity, etc. So, it doesn’t look like
> uncharted waters.
osc has the core service integreated in tree but everything else is done via a plugin including things
like ironic and placement. if we were to start osc again we would either have made everything plugins
or done everything intree. as it stands we have been moving towrord the everything is a plugin side of
that scale. even for nova we have been considering if a plugin would be better in order to allow use more easily
close the gap between the cli and api.

the main disadvantage to integrating osc intree will be review time. e.g. as the cyborg core team
ye will not have +2 rights on osc but if you have your own osc plugin then the cyborg core team
can also manage the cli for cyborg.

> 
> [1] https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html
> [2] https://github.com/openstack/python-openstackclient/tree/master/openstackclient 
> 
> > dt
> 
> Thanks & Regards,
> Sundar