| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-07-25 | |||
| 14:29:46 | Li_Liu | I was looking as it | |
| 14:30:01 | Li_Liu | will provide comments in a bit | |
| 14:30:13 | shaohe_feng | Thanks. | |
| 14:30:27 | shaohe_feng | For sample scenarios | |
| 14:30:50 | shaohe_feng | There is a QAT and FPGA. | |
| 14:31:26 | shaohe_feng | the user want to cypto function. | |
| 14:32:11 | shaohe_feng | pre-programmed cypto FPGA | |
| 14:32:19 | shaohe_feng | how does he do? | |
| 14:33:03 | shaohe_feng | needs host, devices_type, function_type. | |
| 14:33:15 | shaohe_feng | also the numbers? | |
| 14:33:29 | Li_Liu | one way is to use add_attribute() api in Deployable | |
| 14:33:39 | shaohe_feng | maybe he want to 2 pre-programmed cypto FPGAs | |
| 14:33:57 | shaohe_feng | Li_Liu, I did it as you said. | |
| 14:34:02 | Coco | yes, I think number is necessary. | |
| 14:34:17 | Li_Liu | what kind of numbers? | |
| 14:34:23 | Li_Liu | performance kpi? | |
| 14:34:32 | Li_Liu | like 30 gbps? | |
| 14:34:51 | shaohe_feng | Coco, agree. You can also give the comments on that API patches. | |
| 14:34:54 | Coco | the number of deployables allocated at once. | |
| 14:35:13 | wangzhh | GET will return a list of acc. So we need number in allocate? | |
| 14:35:58 | Coco | at least, there are some place in the code where we deal with the number requirement of deployables. | |
| 14:36:07 | wangzhh | Batch allocate? | |
| 14:36:08 | Li_Liu | if we have a dedicated allocation api, then the number should be included | |
| 14:36:50 | Li_Liu | I though for now we are just using the deployable PATCH, which is single allocation | |
| 14:37:18 | Coco | OK, than if user ask for 2, we should use the api twice? | |
| 14:37:28 | Coco | then | |
| 14:37:42 | shaohe_feng | For example, you and I Get 2 accs. | |
| 14:37:48 | Li_Liu | that could a bit tricky | |
| 14:38:07 | shaohe_feng | Then we need allocated them, then risk | |
| 14:39:12 | zhipeng | will user actually needs to simultaneously deploy two kinds of accs ? | |
| 14:39:23 | zhipeng | or more, all at once | |
| 14:39:39 | shaohe_feng | So For my POC. dolpher proposal one API to get and allocated. | |
| 14:40:14 | shaohe_feng | zhipeng, dolper prefer at once. | |
| 14:40:23 | zhipeng | i was thinking about batch actions | |
| 14:40:43 | zhipeng | it makes sense for VMs and containers, since they are mostly homogeneous | |
| 14:40:56 | zhipeng | if fails, rollback is pretty easy | |
| 14:41:07 | Li_Liu | I agree with the multi-alloc use case | |
| 14:41:09 | shaohe_feng | sure. thanks, you got my points. | |
| 14:41:27 | zhipeng | but if we are gonna have batch operation on difference accelerators | |
| 14:41:54 | zhipeng | if they are the same type it will be easy, but for different functionalities, it will be tricky | |
| 14:42:07 | shaohe_feng | It is hard for difference accelerators. | |
| 14:42:17 | shaohe_feng | I have not think a good solutions for it. | |
| 14:42:22 | xinran__ | Cyborg return a list of accelerators and nova will do a for loop to allocate one by one, this is the current solution, but I think we should pass num to cyborg allocate api in the future | |
| 14:42:34 | shaohe_feng | Li_Liu, what's your suggestion on this one? | |
| 14:42:49 | Li_Liu | when calling the dedicated alloc api, just provide the list of acc type you need | |
| 14:42:52 | zhipeng | yes what xinran__ said is okey | |
| 14:43:22 | Li_Liu | for instance, alloc: [aes x 1 + rsa x 2] | |
| 14:43:37 | Li_Liu | that gives you 3 different accs | |
| 14:47:57 | zhipeng | i think we should follow xinran__'s suggestion | |
| 14:48:05 | zhipeng | let's stuck to the current solution for Rocky | |
| 14:48:15 | zhipeng | and discuss about batch in Denver ptg | |
| 14:48:38 | Coco | what's the deadline? | |
| 14:50:16 | zhipeng | client is 27th ... | |
| 14:51:42 | Li_Liu | agree, xinran_'s suggestion should solve the problem for us for now | |
| 14:51:56 | Coco | 2 days left? | |
| 14:52:09 | wangzhh | LIke os-acc before. It is urgent.：） | |
| 14:52:15 | zhipeng | yes lol | |
| 14:52:20 | zhipeng | every release is like this | |
| 14:52:20 | Li_Liu | zhipeng, what else are we trying to squeeze in by 27th? | |
| 14:52:33 | zhipeng | just the client lib final cut | |
| 14:52:51 | zhipeng | meaning the basic api will not be changed as well, after that, to make sure the client works | |
| 14:53:08 | Li_Liu | i see | |
| 14:53:29 | zhipeng | shaohe_feng your new patch | |
| 14:53:30 | zhipeng | https://review.openstack.org/#/c/585146/ | |
| 14:53:37 | zhipeng | is about the placement support right ? | |
| 14:53:49 | zhipeng | do we need to remove some old implementation ? | |
| 14:54:03 | zhipeng | I remember Li Liu coded the report functionality before | |
| 14:54:39 | Li_Liu | https://github.com/openstack/cyborg/blob/master/cyborg/services/report.py | |
| 14:54:43 | Li_Liu | I did this part | |
| 14:55:15 | Li_Liu | shaohe_feng, is it sufficient for you? | |
| 14:55:17 | zhipeng | are there any conflict ? | |
| 14:55:39 | xinran__ | client lib depends on cyborg api we don’t have allocation api right now. How we handle that ? | |
| 14:55:43 | zhipeng | I think shaohe added the provider_tree and also make sure the interaction happens on the agent level | |
| 14:56:03 | zhipeng | xinran__ will zhenghao's patch handle that ? | |
| 14:58:15 | shaohe_feng | Li_Liu, zhipeng I'm back. | |
| 14:58:16 | shaohe_feng | sorry | |
| 14:58:24 | Li_Liu | I guess shaohe_feng re-implemented my part in his new patch.. | |
| 14:58:43 | shaohe_feng | It support the sub-provider. | |
| 14:58:57 | shaohe_feng | actually, I did not re-implemented it. | |
| 14:59:05 | shaohe_feng | I leverage it from nova | |
| 14:59:07 | Li_Liu | shaohe_feng, I have implemented the SchedulerReportClient in https://github.com/openstack/cyborg/blob/master/cyborg/services/report.py | |
| 14:59:34 | shaohe_feng | Li_Liu, yes, I know your implementations. | |
| 14:59:48 | Li_Liu | so what the difference between your SchedulerReportClient and my SchedulerReportClient? just curious | |
| 14:59:58 | shaohe_feng | no sup-provider. | |
| 15:00:09 | shaohe_feng | it support nest provider. | |
| 15:00:24 | shaohe_feng | I think these code should be in a lib | |
| 15:00:31 | Li_Liu | i see, but should be put them together? | |
| 15:00:32 | shaohe_feng | so nova and cyborg can share. | |
| 15:00:50 | Li_Liu | just use your code | |
| 15:01:02 | shaohe_feng | yes. Maybe it need to remove the old one. | |
| 15:01:03 | Li_Liu | ignore my implementation for now then | |
| 15:01:11 | Li_Liu | ok | |
| 15:01:19 | zhipeng | okey | |
| 15:01:30 | shaohe_feng | And the best solution, move them to a common lib shared by nova and cyborg or other project | |
| 15:01:42 | xinran__ | zhipeng: yeah but we need modify that in the future | |
| 15:01:55 | zhipeng | xinran__ yes for sure | |
| 15:02:03 | wangzhh | xinran__， IMHO, we can use PATCH for allocation as my patch in rocky. Or we can design new API interface and parallel development. | |
| 15:02:03 | shaohe_feng | zhipeng, you can talk about with nova's guy, do they have plan to do it? | |
| 15:02:19 | zhipeng | shaohe_feng I think it is a reasonable request | |
| 15:02:33 | zhipeng | since provider tree has also been implemented for nova-compute | |