03:02:08 #startmeeting openstack-cyborg 03:02:09 Meeting started Wed Feb 27 03:02:08 2019 UTC and is due to finish in 60 minutes. The chair is Li_Liu. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:02:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:02:12 The meeting name has been set to 'openstack_cyborg' 03:02:16 Let's get started 03:02:24 Let's get started 03:02:31 #topic Roll Call 03:02:46 #info Li_Liu 03:02:53 #info Sundar 03:02:54 #info wangzhh 03:03:28 o/ 03:03:29 #topic Status Tracking 03:03:42 #info Yumeng 03:03:48 hi all 03:03:51 Hi yumeng 03:04:02 I saw coco just committed the OVO patch 03:04:07 thanks a lot coco 03:04:08 let' 03:04:17 let's try to merge it asap 03:04:41 So that xinran and I can start working on the conductor 03:04:54 Cool. 03:05:27 Is Sundar here? 03:05:38 Still, I got something to discuss with Sundar. 03:05:39 Li_Liu: Yes 03:05:46 I agree 03:05:49 Hi Sundar 03:05:55 Hi Coco_gao 03:06:06 Sundar, if we wanna get a working cyborg-nova integration 03:06:14 #info Coco_gao 03:06:19 can we start something now 03:06:20 ? 03:06:32 I think so 03:07:14 Li_Liu: I think it is a long shot. It has got some review, but we cannot expect the Nova side to remain as is after March 8, as it goes through reviews 03:07:33 So, the details of the APIs would change, even if the overall form does not 03:07:54 i.e. we may still have create ARQ, ind ARQ etc. But the API signatures may change 03:08:02 which means versioning it again 03:08:10 *bind ARQ 03:08:15 Hi all, sorry for late 03:08:54 can we go ahead with a patched based implementation? 03:09:11 so that we can demo this in the summit 03:09:14 LiLiu, Coco_gao, all: Please do review the CYborg pilot code and Nova patches. That will at least reduce the chances that we get surprised later 03:09:33 and apply later changes after we finalize thing with nova 03:09:50 Ok, I will. 03:10:00 OK, sundar. 03:10:13 Sundar, I will review after get in the conductor code :) 03:10:25 Li_Liu: I have plans for a demo with the patches. I am working on getting resource commitments within my co. 03:10:59 I think we can do a demo, even if it is not in the form that will finally merge 03:11:07 ok 03:11:10 sounds good 03:11:12 I will fix the unit test part. 03:12:34 Li_Liu, as for the conductor diff, feel free to discuss with us. 03:12:52 Coco_gao 03:13:07 sure, that part is owned by xinran and I 03:13:20 Sundar, as for my new driver ovo, I still got something to discuss with you. 03:13:45 can the attach_handles have same attach_info, but the attach_type is different? 03:13:54 xinranwang, I think we don't really need 2 people working on it 03:13:59 Coco_gao: Sure. Do you want to do that here, or do you prefer Zoom? 03:14:15 do you have some cycles during the day? 03:14:33 Sundar, maybe zoom or Email 03:14:41 Coco_gao: attach_type is 'PCI', 'mediated_device', etc. SO, if the types are different ,the info will be totally different 03:15:40 Li_Liu: yes, I agree. I can take over this part if needed 03:15:48 E.g. For PCI, attach_info is BDF: {"domain": "0", bud: "5E", ... } 03:16:09 For mediated devices, it will be a UUID that is dynamically created 03:16:13 Coco_gao: Sure. Please feel free to shoot an email, and I can also send a zoom invite 03:16:26 xinranwang, sure. do you have eta for it? 03:16:27 Sundar, thank you. 03:16:27 Sundar, so one deployable can report 2 or more attach_handle? 03:16:38 *attach_handles 03:17:05 wangzhh: Yes. Today's products don't need it (at least for the ones I know about), but it is possible in the future 03:17:32 Sundar, pls help review the new drive ovo patch. 03:17:53 wangzhh: This is the situation when one deployable has 2 or more accelerator resources. Then each one needs a separate attach handle 03:18:05 I hope I didn't mis-understanding your design. 03:18:07 Coco_gao: On it after this meeting 03:18:42 Li_Liu: what's eta? 03:19:30 "Estimated Time of Accomplishing" 03:19:34 :P 03:19:47 lol 03:20:54 Li_Liu: hmmm, i think i can start working on this once OVO part has done, and will submit at least one patch in the following week. 03:21:05 Sundar: The 'accelerator resources' here meas vf or pf here? 03:21:37 Code freeze is next week 03:21:51 wangzhh: We have made a distinction between accelerator resources, which is just a number, from PF (controlpath_id) and VF (attach_handle) 03:22:09 wangzhh, do you have to wait for conductor code for your piece? 03:22:36 Sundar: Got it. 03:23:15 Li_liu: No, just the function name. I can hack it. 03:23:48 ok, let's get wangzhh and xinranwang's patch in before the code freeze 03:24:28 wangzhh: Good. If it helps, please see https://docs.google.com/presentation/d/1Anud3Qbcb0P3G245HpHduHhslx1MJljGD6wqPDy7o9E/edit#slide=id.g44d3e3519f_4_96 03:24:29 I might also fix the FPGA programming api as well. but that should be a minor change 03:24:42 Sundar, I think the original design is that attach_handle can be VF or PF, and controlpath_id is only used for identify a device? Do we change now? 03:24:55 Sundar, Thx. 03:24:58 Li_Liu: Ah yes, but conductor need to call ovo's function as I understood. 03:25:42 xinranwang, that's in coco's patch right? 03:26:08 The function in OVO is used for diff, I can add that part. 03:26:27 Coco_gao: No. We always had a distinction. In the link I posted earlier, the only change I made was to change the term 'DeviceID' to 'ControlPath_ID' 03:26:48 because we use the term 'device_id' in the db layer for something else 03:27:14 Coco_gao, do you need help for them? 03:28:14 Li_Liu: I suspect the programming API needs some changes. It is tied to the device path now. But shuld be tied to deployable UUID or some such, right? 03:28:32 It doesn't have to be done for Stein, though 03:28:49 Sundar, you are right, should not be too much effort 03:28:58 Li_Liu, I will ask zhenghao for help 03:29:11 since we kinda claimed reprogramming API works in last summit 03:29:43 Coco_gao, thanks, also thanks wangzhh :) 03:30:19 Coco_gao: So I will sync with you and wangzhh to start working on conductor part in same time then. 03:31:15 Coco_gao, I can also help. just LMK if you need help 03:32:49 do you think it is better to work in parallel, cause time's rushing by. I can hack the ovo function call in conductor if needed. 03:33:37 Yes, we'd better work in parallel 03:33:51 #info shaohe 03:34:22 morning Coco_gao, evening Li_Liu 03:34:30 hi shaohe 03:34:39 sounds we have pretty good idea on the task before the code freeze 03:34:47 hi shaohe_feng 03:35:27 Let's keep working them and be open to communication through out the freezing phase 03:36:20 zoom meeting room is open all the time, in case you guys want to discuss anything, just ping us on wechat and drop in zoom 03:36:45 #topic AoB 03:37:24 Let's call the meeting then. Thank you guys for the efforts 03:37:38 Have a good day/night 03:37:49 #endmeeting