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