| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-07-25 | |||
| 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 | |
| 15:02:39 | openstackgerrit | Merged openstack/cyborg master: Add "interface_type" field in deployable DB https://review.openstack.org/584296 | |
| 15:02:57 | xinran__ | wangzhh: and deallocate also by patch method ? | |
| 15:02:59 | zhipeng | hey look who's here | |
| 15:03:08 | Li_Liu | a lot of reimplementations cross different project just for this part... | |
| 15:03:13 | shaohe_feng | zhipeng, yes. Need need for us to maintain same code with other project. :) | |
| 15:03:31 | wangzhh | Yes. | |
| 15:03:39 | wangzhh | xinran__ | |
| 15:03:44 | shaohe_feng | Li_Liu, yes. too many. but we should avoid. | |
| 15:03:55 | Li_Liu | agree | |
| 15:04:00 | zhipeng | okey next on drivers | |
| 15:04:05 | shaohe_feng | And that is cyborg should focus on | |
| 15:04:18 | shaohe_feng | that is not | |
| 15:04:20 | shaohe_feng | sorry. | |
| 15:04:35 | zhipeng | we now have gpu and opae based fpga drivers on the fly | |
| 15:05:02 | zhipeng | need brianx__ to start the Xilinx driver ASAP lol | |
| 15:05:10 | xinran__ | Coco: did you modify the driver discover() method to get interface type? | |
| 15:05:11 | zhipeng | let's start with a simple version | |
| 15:05:47 | Coco | I think the yes | |
| 15:06:14 | Coco | I will check again. | |
| 15:07:29 | Coco | I use the "pci" as the "interface_type" value at this moment, since it's fpga driver. | |
| 15:08:12 | wangzhh | I think discover should have common data structure. | |
| 15:08:22 | shaohe_feng | I have list cyborg tasks in the etherpad. include this one | |
| 15:08:25 | Coco | I agree with wangzhh | |
| 15:08:26 | shaohe_feng | No one take it at present. | |
| 15:09:02 | shaohe_feng | Yes. maybe an object | |
| 15:09:02 | Coco | 27th also the deadline? | |
| 15:09:17 | shaohe_feng | then it can not need schema verify | |