| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 14:42:40 | zhipeng | basically a hat on cyborg, if you will | |
| 14:44:11 | Li_Liu | so it's a subscribe/notify model right? | |
| 14:44:41 | zhipeng | in essence, as I understand yes | |
| 14:46:14 | NokMikeR | in go land | |
| 14:47:56 | zhipeng | yep :) | |
| 14:48:02 | NokMikeR | is it trival to use python from go or how does the cyborg api interaction work to k8 and go? | |
| 14:48:28 | zhipeng | we could have gRPC clients that abstract away the lang difference | |
| 14:48:45 | NokMikeR | ok | |
| 14:49:17 | NokMikeR | I need that for English to Finnish to English also :) | |
| 14:50:09 | zhipeng | haha | |
| 14:50:22 | zhipeng | you need google duplex for that :P | |
| 14:51:10 | NokMikeR | :) | |
| 14:51:17 | sundar | Exactly, gRPC -- as Zhipeng said. The controller is a separate daemon. Also, kubelet and Cyborg DP will also be separate processes. | |
| 14:52:34 | zhipeng | let's keep discussion alive offline :) | |
| 14:52:49 | zhipeng | #topic bugs and issues | |
| 14:53:26 | zhipeng | shaohe a colleague of mine report that when devstack starts, he could not find cyborg services | |
| 14:53:37 | zhipeng | have you encountered similar problem ? | |
| 14:55:28 | zhipeng | shaohe dropped i think | |
| 14:55:39 | zhipeng | okey let's move on to the next topic then | |
| 14:55:43 | NokMikeR | I reported the same problem many moons ago, but have not tried lately to install it | |
| 14:56:31 | zhipeng | NokMikeR i think during some of the past fixes it turns out ok | |
| 14:56:42 | zhipeng | i'm not sure if some of the recent patches breaks it | |
| 14:57:45 | NokMikeR | the mutable config page shows a failure? https://review.openstack.org/#/c/559303/ | |
| 14:58:08 | shaohe_ | ping | |
| 14:58:23 | zhipeng | hey welcome back | |
| 14:58:25 | NokMikeR | pong | |
| 14:58:32 | zhipeng | NokMikeR that should be already fixed | |
| 14:58:38 | NokMikeR | ok | |
| 15:00:09 | zhipeng | so the specific problem is c-cond and c-agent are not running | |
| 15:00:24 | zhipeng | shaohe_ that is not normal right / | |
| 15:00:55 | shaohe_ | yes. | |
| 15:01:23 | zhipeng | if devstack succeed | |
| 15:01:38 | shaohe_ | devstack should report error, if c-cond and c-agent are not running | |
| 15:01:38 | zhipeng | c-api, c-cond, c-agent should all be running right ? | |
| 15:02:24 | zhipeng | ok i will contact the author | |
| 15:02:28 | zhipeng | okey moving on | |
| 15:03:18 | zhipeng | #topic spec review day | |
| 15:03:28 | shaohe_ | it should be cyborg-agent, cyborg-api, cyborg-cond | |
| 15:03:38 | zhipeng | nova and other team all have this custom of spec sprint, or runways | |
| 15:03:43 | zhipeng | let's have one as well | |
| 15:03:51 | zhipeng | shaohe_ ok I will let him know | |
| 15:04:08 | zhipeng | #link https://etherpad.openstack.org/p/cyborg-rocky-spec-day | |
| 15:04:12 | shaohe_ | is c-xxx cinder process? | |
| 15:04:25 | zhipeng | maybe he just referred wrong | |
| 15:04:31 | zhipeng | I should double check with him | |
| 15:04:48 | shaohe_ | yes | |
| 15:05:34 | zhipeng | okey back to topic | |
| 15:06:26 | zhipeng | let's start with the "old ones" :) | |
| 15:06:33 | zhipeng | we should be ready to land those | |
| 15:07:06 | zhipeng | first up | |
| 15:07:09 | zhipeng | #info python-cyborgclient framework | |
| 15:07:19 | zhipeng | #link https://review.openstack.org/565023 | |
| 15:07:35 | zhipeng | shaohe_ mentioned the client code is actually ready, so let's land this one | |
| 15:07:40 | zhipeng | any objections ? | |
| 15:07:48 | Li_Liu | agree, I think we can merge that one | |
| 15:07:54 | sundar | I think the syntax is not quite in line? | |
| 15:08:05 | Li_Liu | just finished reviewing | |
| 15:08:15 | sundar | Other commands are like 'openstack server ...' where the 2nd argument is the object on which an action is applied | |
| 15:08:50 | sundar | Whereas we are proposing 'openstack acceleration ...' I saw Shaohe respond to my comment. | |
| 15:09:18 | sundar | It is not clear to me why we cannot have 'openstack acelerator <list/show/...>' | |
| 15:09:54 | NokMikeR | wondering why its not openstack cyborg list/show ? | |
| 15:09:57 | zhipeng | because accelerator more like an object that we will choose to act upon | |
| 15:10:06 | zhipeng | NokMikeR legal issue | |
| 15:10:12 | NokMikeR | ok | |
| 15:10:32 | sundar | NokMikeR: Just as we have 'openstack server ..' instead of 'openstack nova ' | |
| 15:10:45 | shaohe_ | cyborg is project name, acceleration is service type. | |
| 15:10:46 | edleafe | yeah - project names should be avoided | |
| 15:11:00 | NokMikeR | clarified thanks. | |
| 15:11:14 | Li_Liu | that's good to know :) | |
| 15:11:42 | sundar | shaohe: It is not clear to me why we cannot have 'openstack accelerator <list/show/...>' | |
| 15:12:03 | zhipeng | sundar see my above comment | |
| 15:12:09 | zhipeng | because accelerator more like an object that we will choose to act upon | |
| 15:12:24 | zhipeng | acceleration is a type of service, like server service, volume service | |
| 15:12:46 | sundar | zhipeng, yes. Like server/image etc. shouldn't it be the 2nd arg? | |
| 15:12:54 | zhipeng | we might have something like openstack acceleration fpga create | |
| 15:13:15 | zhipeng | shaohe_ correct me if I'm wrong | |
| 15:13:32 | shaohe_ | yes. I have look other project. | |
| 15:13:48 | shaohe_ | they do use this syntax | |
| 15:14:01 | shaohe_ | some use this syntax | |
| 15:14:07 | NokMikeR | is it command(create) then object(fpga) ? | |
| 15:15:05 | NokMikeR | openstack [<global-options>] <object-1> <action> [<object-2>] [<command-arguments>] | |
| 15:15:25 | shaohe_ | yes as NokMikeR suggestion | |
| 15:15:37 | zhipeng | NokMikeR yes the example i mentioned might not be strictly correct :P | |
| 15:15:40 | shaohe_ | global-options can be service type | |
| 15:16:12 | shaohe_ | for cyborg the service type is acceleration. | |
| 15:16:29 | shaohe_ | for cinder the service type is volume | |
| 15:16:43 | edleafe | #link openstackclient guidelines: https://docs.openstack.org/python-openstackclient/3.4.1/humaninterfaceguide.html#command-structure | |
| 15:16:44 | shaohe_ | for glance the service type is image | |
| 15:16:47 | sundar | shaohe: May be I still have a disconnect. :) "openstack [<global-options>] <object-1> <action> [<object-2>] [<command-arguments>]" Where is the service here? | |
| 15:17:11 | edleafe | sundar: object-1 | |
| 15:18:06 | sundar | So, we will have syntax like 'openstack acceleration create <object-2> ...' | |
| 15:18:49 | zhipeng | something like that | |
| 15:18:52 | sundar | If everybody else is ok with it, I am ok too :) | |
| 15:18:52 | shaohe_ | openstack network --help |less | |
| 15:19:07 | edleafe | I would suggest s/acceleration/accelerator | |
| 15:19:15 | shaohe_ | openstack network flavor create | |
| 15:19:52 | zhipeng | edleafe any reason for that ? | |
| 15:20:04 | sundar | IMHO, the term 'accelerator' is more in line with other usages -- but go ahead :) | |
| 15:20:16 | edleafe | ^^ what sundar said | |
| 15:21:06 | zhipeng | ya I'm just thinking when we actually using accelerator it will need to be more specific (FPGA, GPU, ...) | |