| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-03-21 | |||
| 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 | |
| 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 | |
| 15:01:13 | shaohe_feng_ | they are both http request. | |
| 15:01:18 | zhipeng | anyways this has been discussed in extent with Nova team and let's stay with the conclusion | |
| 15:01:24 | Li_Liu | ok | |
| 15:01:30 | zhipeng | shaohe_feng_ we could discuss offline more with Alex | |
| 15:01:31 | shaohe_feng_ | OK | |
| 15:01:38 | zhipeng | but let's not dwell on it | |
| 15:01:51 | Sundar | May be I misunderstood :) We are proposing a weigher maintained in Cyborg tree, which the operator will configure in nova.conf. Is that a concern? | |
| 15:02:34 | shaohe_feng_ | weigher maintained in Cyborg tree, still need one cyborg api request, so also performance issue? | |
| 15:03:02 | zhipeng | Sundar I don't think that would be a concern | |
| 15:03:06 | Sundar | shaohe: I personally don't think so, but we'll check the data to assure everybody | |
| 15:03:24 | shaohe_feng_ | zhipeng: Li_Liu: do you think a weigher maintained in Cyborg tree is a good idea? | |
| 15:03:47 | zhipeng | yes, at the moment | |
| 15:04:09 | shaohe_feng_ | Sundar: you still need to tell cyborg which hosts need to weight | |
| 15:04:22 | shaohe_feng_ | on cyborg api call. | |
| 15:04:22 | Sundar | shaohe: This weigher is querying Cyborg DB. It is better to keep it in Cyborg | |
| 15:04:39 | Li_Liu | I agree with zhipeng | |
| 15:04:56 | zhipeng | the weigher will just talk to the conductor | |
| 15:05:02 | zhipeng | it is not blocking nova operations | |
| 15:05:06 | zhipeng | that is the point | |
| 15:05:59 | shaohe_feng_ | any the way, the api call will talk to conductor to query Cyborg DB | |
| 15:06:06 | Sundar | Shaohe, yes. The weigher gets a list of hosts. We could either introduce a new Cyborg API for that, or just have the weigher query the db directly | |
| 15:06:09 | shaohe_feng_ | no difference. | |
| 15:06:23 | zhipeng | shaohe_feng_ let's leave it offline | |
| 15:06:29 | shaohe_feng_ | zhipeng: OK. | |
| 15:06:46 | zhipeng | Sundar thx for the spec :) | |
| 15:06:57 | zhipeng | We will definitely review it more | |
| 15:07:51 | zhipeng | next up, Li Liu's patch | |