On Thu, 2019-05-23 at 09:10 -0500, Eric Fried wrote:

Hi Ikuo. I'm glad you're interested in helping out with this effort.

I'm trying to understand where you intend to make your changes, assuming you're coming at this purely from a cyborg perspective:

- If in Nova, this isn't necessary because there's no python-cyborgclient integration there. Communication from Nova to Cyborg is being added as part of blueprint nova-cyborg-interaction [0], but it'll be done without python-cyborgclient from the start. The patch at [1] sets up direct REST API communication through a KSA adapter. Once we have base openstacksdk enablement in Nova [2] we can simply s/get_ksa_adapter/get_sdk_adapter/ at [3]. And in the future as the sdk starts supporting richer methods for cyborg, we can replace the direct REST calls in that file (see [4] later in that series to get an idea of what kinds of calls those will be).

- If in the cyborg CLI, I'm afraid I have very little context there. There's a (nearly-official [5]) community push to make all CLIs OSC-based. I'm not sure what state the cyborg CLI is in, but I would have expected it will need brand new work to expose the v2 changes being done for Train. From that perspective I would say: do that via OSC. But that's not really related to bp/openstacksdk-in-nova. given the cyborg api has 2 enpoint with like 10 effective action you can prefrom

crun operation on acclerator + deployable + program it shoudl be trivail to add port to an osc pugin at this point. if you add the api suport to the openstack sdk frist you can kill two brid with one stone and just make the osc plugin for cyborg call the sdk function then compltel drop python-cyborgclient cfom a nova integration point of view we could then also jsut use the sdk functions.

- If in python-cyborgclient, again I lack background, but I don't think there's a need to make changes here. The point of bp/openstacksdk-in-nova (or openstacksdk-anywhere) is to get rid of usages of client libraries like python-cyborgclient. Where is python-cyborgclient being used today? If it's just in the CLI, and you can make the above (conversion to OSC) happen, it may be possible to retire python-cyborgclient entirely \o/

Now, if you're generally available to contribute to either bp/nova-cyborg-interaction (by helping with the nova code) or bp/openstack-sdk-in-nova (on non-cyborg-related aspects), I would be delighted to get you ramped up. We could sure use the help. Please let me know if you're interested.

Thanks, efried

[0] https://blueprints.launchpad.net/nova/+spec/nova-cyborg-interaction [1] https://review.opendev.org/#/c/631242/ [2] https://review.opendev.org/#/c/643664/ [3] https://review.opendev.org/#/c/631242/19/nova/accelerator/cyborg.py@23 [4] https://review.opendev.org/#/c/631245/13/nova/accelerator/cyborg.py [5] https://review.opendev.org/#/c/639376/

On 5/23/19 7:58 AM, Ikuo Otani wrote:

...

Hi,

I am a Cyborg member and take the role of integrating openstacksdk and replacing use of python-*client. Related bluespec: https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova

My question is: When the first code should be uploaded to gerrit? From my understanding, we should update cyborg client library referring to openstacksdk rule, and make it reviewed in gerrit by Eric Fried. I'm sorry if I misunderstand.

Thanks in advance, Ikuo

NTT Network Service Systems Laboratories Server Network Innovation Project Ikuo Otani TEL: +81-422-59-4140 Email: ikuo.otani.rw@hco.ntt.co.jp

We need changes in Cyborg CLI for version 2 (which enables Nova integration, and introduces new objects in the process). New CLIs are supposed to be based on OpenStackClient [1]. Not sure if that is mandatory, but seems like a good idea if we have to redo significant parts of the CLI anyway.

+1

The CLI from python-cyborgclient is based on the OpenStack CLI syntax. However, AFAICS, it is not a plugin into OSC. For example, it does not do "from openstackclient import shell". The list of OpenStack CLI plugins [3] does not include Cyborg.

Does this mean that python-cyborgclient should be rewritten as an OSC plugin?

Ultimately yes*. Both can exist concurrently, so for the sake of not accruing further technical debt, you might consider starting the OSC plugin piece with v2 and porting v1 functionality gradually/later. (Or maybe not at all. Is the v1 API a real thing that's going to be maintained long term?) Eventually the goal would be to retire the non-OSC CLI pieces. *or starting a new osc-cyborg project for the plugin

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.

Agreed. I think the overlap is that a given OSC plugin can (with at least an undercurrent of "should") use the SDK. Since cyborg is starting both OSC and v2 from scratch, I would definitely say write the OSC code to talk through SDK. efried .

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> 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/humanin... [2] https://github.com/openstack/python-openstackclient/tree/master/openstackcli...

dt

Thanks & Regards, Sundar

On Thu, May 30, 2019 at 5:00 AM Sean Mooney <smooney@redhat.com> wrote:

...

$ 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

The resource name should be clear and descriptive and unique. Depending on the set of resources you have in whole you may want 'accelerator profile', I would leave 'device' out as it does not really add anything unless you also have other types of profiles.

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.

This is true, the number of people reviewing regularly on OSC outside their specific project commands is small. dt -- Dean Troyer dtroyer@gmail.com

On Thu, May 30, 2019 at 5:22 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:

The osc documentation [1] says the syntax should be 'object-1 action object-2'. Your other points are well-taken.

[1] https://docs.openstack.org/python-openstackclient/latest/contributor/humanin...

For commands that involve two resources, yes. There are only a handful of commands with two resources (objects).

The object itself is called a device profile, in the specs and in code.

To be honest I don't care what the specs or code call it, what is important is what the users will know it as. 'device profile' needs a qualifier it is too generic. 'accelerator device profile' and 'accelerator profile' mean the same thing to me if you decide that the type of device you are referring to is an accelerator. The only way to stick with 'device profile' is to add an option defining the type, similar to how the limits and quota commands work.

...

This is true, the number of people reviewing regularly on OSC outside their specific project commands is small.

This may be the clinching argument. Also, Sean's observation that "as it stands we have been moving [toward] the everything is a plugin side of that scale." Since we need to deliver the client by Train, and the Cyborg team doing that is also doing other activities, perhaps we should keep the timeline as the main factor.

Sean does not speak for the OSC team, that seems to be a sentiment expressed last fall by some Nova devs. You do what is right for your team, I want you to have correct information to make that decision. I am not aware of any actual effort to remove any of the commands from the OSC repo either now or in the forseeable future. dt -- Dean Troyer dtroyer@gmail.com

Hi Eric, I'm sorry for late reply. Your kind explanation made me understand. Our situation is as Sundar mentioned. I am a beginner for developing openstack, but I will try to make cyborgclient more elaborate anyway! Thanks, Ikuo -----Original Message----- From: Eric Fried <openstack@fried.cc> Sent: Thursday, May 23, 2019 11:10 PM To: openstack-discuss@lists.openstack.org Subject: Re: [cyborg][nova][sdk]Cyborgclient integration Hi Ikuo. I'm glad you're interested in helping out with this effort. I'm trying to understand where you intend to make your changes, assuming you're coming at this purely from a cyborg perspective: - If in Nova, this isn't necessary because there's no python-cyborgclient integration there. Communication from Nova to Cyborg is being added as part of blueprint nova-cyborg-interaction [0], but it'll be done without python-cyborgclient from the start. The patch at [1] sets up direct REST API communication through a KSA adapter. Once we have base openstacksdk enablement in Nova [2] we can simply s/get_ksa_adapter/get_sdk_adapter/ at [3]. And in the future as the sdk starts supporting richer methods for cyborg, we can replace the direct REST calls in that file (see [4] later in that series to get an idea of what kinds of calls those will be). - If in the cyborg CLI, I'm afraid I have very little context there. There's a (nearly-official [5]) community push to make all CLIs OSC-based. I'm not sure what state the cyborg CLI is in, but I would have expected it will need brand new work to expose the v2 changes being done for Train. From that perspective I would say: do that via OSC. But that's not really related to bp/openstacksdk-in-nova. - If in python-cyborgclient, again I lack background, but I don't think there's a need to make changes here. The point of bp/openstacksdk-in-nova (or openstacksdk-anywhere) is to get rid of usages of client libraries like python-cyborgclient. Where is python-cyborgclient being used today? If it's just in the CLI, and you can make the above (conversion to OSC) happen, it may be possible to retire python-cyborgclient entirely \o/ Now, if you're generally available to contribute to either bp/nova-cyborg-interaction (by helping with the nova code) or bp/openstack-sdk-in-nova (on non-cyborg-related aspects), I would be delighted to get you ramped up. We could sure use the help. Please let me know if you're interested. Thanks, efried [0] https://blueprints.launchpad.net/nova/+spec/nova-cyborg-interaction [1] https://review.opendev.org/#/c/631242/ [2] https://review.opendev.org/#/c/643664/ [3] https://review.opendev.org/#/c/631242/19/nova/accelerator/cyborg.py@23 [4] https://review.opendev.org/#/c/631245/13/nova/accelerator/cyborg.py [5] https://review.opendev.org/#/c/639376/ On 5/23/19 7:58 AM, Ikuo Otani wrote:

Hi,

I am a Cyborg member and take the role of integrating openstacksdk and replacing use of python-*client. Related bluespec: https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova

My question is: When the first code should be uploaded to gerrit? From my understanding, we should update cyborg client library referring to openstacksdk rule, and make it reviewed in gerrit by Eric Fried. I'm sorry if I misunderstand.

Thanks in advance, Ikuo

NTT Network Service Systems Laboratories Server Network Innovation Project Ikuo Otani TEL: +81-422-59-4140 Email: ikuo.otani.rw@hco.ntt.co.jp