From: Dean Troyer <dtroyer@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@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
On Thu, 2019-05-30 at 03:51 +0000, Nadathur, Sundar wrote: 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/humanin... [2] https://github.com/openstack/python-openstackclient/tree/master/openstackcli...
dt
Thanks & Regards, Sundar