| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-07-25 | |||
| 14:16:52 | shaohe_feng | just for I do not touch more cyborg code | |
| 14:17:25 | xinran__ | I think there should be an unified api which does allocation and unallocation | |
| 14:17:41 | zhipeng | xinran__ what do you mean by unified ? | |
| 14:17:50 | xinran__ | Instead of implementing in deployable api | |
| 14:17:52 | shaohe_feng | the PATCH method, it is for resource, not for collections. So it can not support batch allocation | |
| 14:17:53 | Coco | #info Coco | |
| 14:18:03 | Li_Liu | 1 api for both alloc and unalloc? | |
| 14:18:16 | xinran__ | I mean another independent api :) | |
| 14:18:27 | Coco | 2 independent api. | |
| 14:18:28 | xinran__ | #info xinran__ | |
| 14:18:57 | Li_Liu | shaohe_feng, i think as least there is no harm to have the PATCH method, even for long term | |
| 14:19:37 | shaohe_feng | #link https://github.com/shaohef/cyborg/commit/13cb904809376584f3cf78b7d7f120817d83c2ad | |
| 14:19:52 | shaohe_feng | this is a poc about half years ago | |
| 14:20:07 | Coco | patch method can keep, but patch can do many things, not only allocate or unallocate. | |
| 14:20:15 | zhipeng | I agree with Li_Liu's assessment, should be good at the moment | |
| 14:20:15 | shaohe_feng | I use it PATCH for unallocation | |
| 14:20:35 | shaohe_feng | { "op": "replace", "path": "/instance_uuid", "value": null } | |
| 14:20:35 | shaohe_feng | [ | |
| 14:20:35 | shaohe_feng | -H "Accept: application/json" -H "X-Auth-Token: $(openstack token issue -f value -c id)" -d ' | |
| 14:20:35 | shaohe_feng | curl -g -i -X PATCH http://localhost:6666/deployables/$UUID -H "Content-Type: application/json" \ | |
| 14:20:36 | shaohe_feng | ]' | |
| 14:21:06 | shaohe_feng | I agree we do not touch two many codes for cyborg at present. | |
| 14:22:31 | shaohe_feng | tiny change is OK for me as https://review.openstack.org/#/c/584641/ | |
| 14:22:51 | zhipeng | okey then let's wrap up zhenghao and coco's patch, and shaohe_feng could update the cyborgclient | |
| 14:23:08 | zhipeng | I will need to cut the final release for client on 27th | |
| 14:23:09 | wangzhh | So, everyone agree that we should have two another apis for allocate or unallocate? | |
| 14:23:20 | shaohe_feng | but we need dolpher/sunder or Li_Liu comments for it. | |
| 14:23:24 | wangzhh | and... | |
| 14:23:55 | shaohe_feng | we can not get the expect deployables. | |
| 14:24:13 | shaohe_feng | for we need more attributes. | |
| 14:24:28 | wangzhh | shaohe_feng, we can extend parameters if dolpher/sunder or Li_Liu have other comments. | |
| 14:24:49 | shaohe_feng | such as function ID/name and more | |
| 14:25:23 | Li_Liu | shaohe_feng so you want to add more fields in the table? | |
| 14:25:36 | wangzhh | API is stable. Just extend the filter for querying. | |
| 14:26:17 | wangzhh | Li_Liu, not db. It's for API. | |
| 14:26:45 | Li_Liu | adding fields should not affect api tho | |
| 14:26:45 | shaohe_feng | For example, I want a crypto FPGA(pre-pre-programmed) | |
| 14:27:17 | shaohe_feng | Yes. so you give the comments ASAP | |
| 14:27:37 | shaohe_feng | need just need experts comments | |
| 14:27:51 | zhipeng | Li_liu plz take a look at https://review.openstack.org/#/c/584641/ | |
| 14:28:20 | zhipeng | and also coco's patch | |
| 14:28:22 | zhipeng | https://review.openstack.org/584296 | |
| 14:28:37 | zhipeng | Li_Liu if you are ok with it plz go head w+1 | |
| 14:28:44 | zhipeng | to land it | |
| 14:28:50 | shaohe_feng | As we have talked, it is easy to improve these patches, as your comments arrives. :) | |
| 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? | |