| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-03-21 | |||
| 14:26:16 | kosamara | Sundar: yes, I'm just making a hypothesis. I expect it can't, but perhaps zeroing-out the ram is a general enough operation and it can do it...? | |
| 14:27:40 | Vipparthy | hi | |
| 14:27:49 | shaohe_feng_ | kosamara: is zeroing-out the ram time consuming？ | |
| 14:28:20 | Sundar | kosamara: I am not a Nvidia expert. But presumably, to access the RAM, one would need to look at the PCI BAR space and find the base address or something? If so, that would be device-specific | |
| 14:29:49 | kosamara | Sundar: thanks for the input. I can research the feasibility of this option this week. | |
| 14:30:15 | zhipeng | kosamara I will also talk to the NVIDIA OpenStack team about it | |
| 14:30:26 | zhipeng | see if we could come out with something for Rocky :) | |
| 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 | Sundar | Shaohe, thanks :) | |
| 14:53:28 | shaohe_feng_ | but I have a question. why nova developer think the accelerator weigher call cause performance loss | |
| 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 | zhipeng | that is still , per host | |
| 14:57:36 | Li_Liu | you mean the weigher is on the Cyborg controller side? | |
| 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 | |