[cyborg][nova][sdk]Cyborgclient integration

Nadathur, Sundar sundar.nadathur at intel.com
Thu May 30 03:51:46 UTC 2019

> 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>

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.

[1] https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html
[2] https://github.com/openstack/python-openstackclient/tree/master/openstackclient 

> dt

Thanks & Regards,

More information about the openstack-discuss mailing list