Earlier  
Posted Nick Remark
#openstack-cyborg - 2018-07-25
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
15:09:53 shaohe_feng anyway, the goal is unify the discover data
15:10:22 Coco I can take it, but can't make sure it can be done by 27th.
15:10:41 Li_Liu when discover() reports data, it should be in Cyborg understandable format
15:10:41 zhipeng does that affect the API behaviour ?
15:11:01 shaohe_feng Coco, great, thanks.
15:11:09 wangzhh zhipeng, no. Just affect agent.
15:11:28 wangzhh To report data.
15:11:29 Li_Liu no affect on api I don't think
15:11:32 zhipeng okey then there is no hurry

Earlier   Later