| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-03-21 | |||
| 14:30:45 | kosamara | shaohe_feng_: I don't have a number right now. It should depend on the manner: if it happens on the device without pci transports it should be quite fast. | |
| 14:31:08 | kosamara | zhipeng thanks :) | |
| 14:32:01 | zhipeng | kosamara is there anything like an architecture diagram for the use case ? | |
| 14:32:20 | kosamara | Not really. | |
| 14:32:32 | zhipeng | okey :) | |
| 14:33:00 | Sundar | kosamara: you also mentioned quotas on GPUs? | |
| 14:33:03 | kosamara | What exactly do you mean by architecture diagram? | |
| 14:33:09 | Li_Liu | this rings a bell to me about the driver apis | |
| 14:33:20 | zhipeng | kosarama like the overall setup | |
| 14:33:33 | Li_Liu | currently we have report() and program() for the vendor driver api | |
| 14:33:50 | kosamara | Yes. We currently implement quotas indirectly. We only allow GPU flavors on specific projects and quota them by cpu. | |
| 14:33:58 | Li_Liu | we might want to consider a reset() api for the drivers | |
| 14:34:09 | zhipeng | Li_Liu makes sense | |
| 14:34:21 | zhipeng | kosamara we will also have quota support for Rocky | |
| 14:34:22 | shaohe_feng_ | +1 | |
| 14:35:13 | kosamara | Good to know. | |
| 14:35:28 | zhipeng | okey folks let's move on to the next topic | |
| 14:35:36 | zhipeng | thx again kosamara | |
| 14:35:40 | kosamara | thanks! | |
| 14:35:47 | shaohe_feng_ | kosamara: so do you not support GPU quota for specific projects？ | |
| 14:35:56 | zhipeng | #topic subteam lead report | |
| 14:36:04 | kosamara | No, we do it indirectly, in the way I mentioned. | |
| 14:36:24 | zhipeng | shaohe_feng_ scrow up :) | |
| 14:36:39 | zhipeng | scroll | |
| 14:37:02 | zhipeng | okey yumeng could you introduce the progress on your side ? | |
| 14:37:43 | zhipeng | Yumeng__ | |
| 14:39:24 | Yumeng__ | Last week I set up a repository for cyborg-specs | |
| 14:40:24 | Yumeng__ | some patches are still waiting for review from the infra team | |
| 14:40:49 | Yumeng__ | Hope it could be merged ASAP | |
| 14:40:55 | Sundar | Are we not using the git repo's doc/specs/ area anymore? | |
| 14:41:14 | zhipeng | Sundar we are migrating it out :) | |
| 14:41:22 | Sundar | Maybe I am missing the context. What is this repository for specs? | |
| 14:41:27 | zhipeng | but it is fine now to keep submit to that folder | |
| 14:41:46 | zhipeng | we will migrate all the approved specs after MS1 to cyborg-specs | |
| 14:42:11 | Sundar | Howard, could you explain why we are doing that? | |
| 14:42:36 | zhipeng | It would be better for the documentation when we do release | |
| 14:42:47 | zhipeng | all the core projects are doing it | |
| 14:43:33 | zhipeng | i think yumeng also add the gate check on docs for cyborg-specs | |
| 14:44:13 | crushil | Sundar All the core projects split out the specs and the main project. So, it makes sense to follow suite | |
| 14:44:31 | zhipeng | yes exactly | |
| 14:44:35 | Sundar | IIUC, in the git repo, approved specs will be doc/specs/<release>/approved, but in the new repo, all release specs will be in one place. Is that right? | |
| 14:45:03 | zhipeng | it will still follows the similar directory structure | |
| 14:45:36 | Sundar | OK, so we are just separating code from docs | |
| 14:45:41 | zhipeng | yes | |
| 14:45:48 | zhipeng | from specs to be preceise | |
| 14:45:50 | zhipeng | precise | |
| 14:45:57 | Sundar | Got it, thanks :) | |
| 14:46:08 | zhipeng | since general documentation is still in cyborg repo, if I understand correctly | |
| 14:46:09 | Li_Liu | for now we still check in the docs to the code repo right? | |
| 14:46:19 | zhipeng | Li_Liu yes, nothing changes | |
| 14:46:24 | Li_Liu | ok | |
| 14:46:40 | zhipeng | thx to Yumeng__ for the quick progress | |
| 14:46:56 | Sundar | In future releases, would we check specs into code repo, and have it be migrated after approval? | |
| 14:47:04 | Yumeng__ | zhipeng: :) | |
| 14:47:21 | zhipeng | in the future we will just submit the spec patch to cyborg-specs | |
| 14:47:37 | Sundar | ok | |
| 14:47:56 | zhipeng | shaohe_feng_ any update on the python-cyborgclient ? | |
| 14:48:03 | shaohe_feng_ | the spec and code will separated | |
| 14:48:41 | shaohe_feng_ | zhipeng: jinghan has some personal staff these days. So no more update. | |
| 14:48:58 | shaohe_feng_ | zhipeng: I will help him on it. | |
| 14:49:18 | zhipeng | thx :) was just gonna mention this | |
| 14:49:24 | zhipeng | plz work with him | |
| 14:49:29 | shaohe_feng_ | hopeful we will make progress next week. | |
| 14:49:30 | shaohe_feng_ | OK | |
| 14:49:36 | zhipeng | ok thx | |
| 14:49:49 | zhipeng | I will work with zhuli on the os-acc | |
| 14:50:10 | zhipeng | that one will most likely involve nova team discussion | |
| 14:50:54 | Sundar | Yes. I will be happy to work with zhuli if he needs any help | |
| 14:51:14 | zhipeng | Sundar gr8t :) | |
| 14:51:26 | zhipeng | #topic rocky spec/patch discussion | |
| 14:51:52 | zhipeng | #link https://review.openstack.org/#/q/status:open+project:openstack/cyborg | |
| 14:52:37 | zhipeng | first up, Sundar's spec patch | |
| 14:53:13 | shaohe_feng_ | Sundar: good work | |
| 14:53:28 | shaohe_feng_ | but I have a question. why nova developer think the accelerator weigher call cause performance loss | |
| 14:53:28 | Sundar | Shaohe, thanks :) | |
| 14:53:39 | zhipeng | #link https://review.openstack.org/#/c/554717/ | |
| 14:53:59 | Sundar | I think the assumption was that the weigher will call into Cyborg REST API for each host | |
| 14:54:09 | Sundar | If the weigher is in Nova tree, that is true | |
| 14:54:25 | Sundar | But, if Cyborg keeps it, we have other options | |
| 14:54:27 | shaohe_feng_ | Sundar: why for each host? | |
| 14:54:51 | Sundar | The typical filter today operates per host | |
| 14:54:52 | shaohe_feng_ | Sundar: I have discussed it before. | |
| 14:55:18 | shaohe_feng_ | Sundar: the cyborg API will run on controller node. | |
| 14:55:32 | shaohe_feng_ | Sundar: we only call the api in controller node. | |
| 14:55:39 | shaohe_feng_ | just on api is OK. | |
| 14:56:13 | shaohe_feng_ | for example, the scheduler filter choose the suitable hosts | |
| 14:56:56 | shaohe_feng_ | and the scheduler weigher just call a API to query the accelerator infos of these hosts | |
| 14:57:05 | shaohe_feng_ | zhipeng: Li_Liu: right? | |
| 14:57:36 | Li_Liu | you mean the weigher is on the Cyborg controller side? | |
| 14:57:36 | zhipeng | that is still , per host | |
| 14:57:56 | shaohe_feng_ | zhipeng: no, we get list for filter API | |
| 14:58:32 | Sundar | Shaohe, yes, we could override the BaseWeigher and handle multiple hosts in one call. That call could invoke Cyborg REST API. | |
| 14:58:44 | shaohe_feng_ | for example: GET /cyborg/v1/accelerators?hosts=cyborg-1,cyborg-2&type=fpga | |
| 14:58:45 | Sundar | To me, it is not clear what the performance hit would be. | |
| 14:59:26 | Sundar | I suspect any performance hit would not be noticeable until we get to some scale | |
| 14:59:28 | Li_Liu | Does this involve the 2-stages scheduling problem we were trying to avoid? | |
| 15:00:10 | Sundar | There is no 2-stage scheduling here: the proposed filter/weigher is a typical one, which just filters hosts based on function calls. | |
| 15:00:26 | shaohe_feng_ | Sundar: yes, the scheduler has call placement several times, is there performance issue? | |
| 15:00:29 | zhipeng | Sundar I think Li_Liu meant for weigher in Nova | |
| 15:00:52 | zhipeng | shaohe_feng_ it is not the same thing | |