| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 14:34:10 | zhipeng | that could all be done in Cyborg | |
| 14:35:18 | zhipeng | for example if you look at kubernetes service catalog | |
| 14:35:25 | Li_Liu | k8s will do the scheduling for Cyborg then? | |
| 14:35:43 | zhipeng | we could use scheduling extention maybe for that | |
| 14:36:31 | zhipeng | but I doubt Google wants to have the k8s core doing scheduling that taking accelerators into consideration | |
| 14:37:46 | Li_Liu | but the scheduling extension still require some change in k8s main tree right? | |
| 14:37:46 | sundar | The Cyborg implementation could relate different resources. Agreed. The CRD discussions also seem to get into resource classes etc., which seem to be a long shot, as you said. Yes, agreed that scheduling core cannot be changed | |
| 14:38:10 | sundar | Li_Liu: scheduler extension is a standard mechanism in K8s today | |
| 14:38:21 | zhipeng | yep what sundar said | |
| 14:38:33 | sundar | However, the scheduler framework itself may evolve, and the extension APIs may change along with it | |
| 14:39:12 | sundar | Link to proposed K8s scheduler framework: https://docs.google.com/document/d/1NskpTHpOBWtIa5XsgB4bwPHz4IdRxL1RNvdjI7RVGio/edit# | |
| 14:40:45 | zhipeng | #link https://medium.com/@trstringer/create-kubernetes-controllers-for-core-and-custom-resources-62fc35ad64a3 | |
| 14:40:52 | zhipeng | some crd fundamentals | |
| 14:41:40 | shaohe | zhipeng: can not open it. | |
| 14:41:49 | zhipeng | so as I understand, crd is basically a way that we write a non-core k8s-ish controller | |
| 14:41:53 | zhipeng | shaohe you need vpn | |
| 14:42:07 | zhipeng | it listens upon the api-server | |
| 14:42:28 | zhipeng | and the keyword will trigger the request going to the crd controller, instead of the core k8s controller | |
| 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 | |