| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-02-27 | |||
| 02:59:52 | Li_Liu | Hi Coco | |
| 02:59:53 | Kevin_Zheng | o/ | |
| 02:59:58 | Li_Liu | Hi guys | |
| 03:00:04 | wangzhh | Hi all. | |
| 03:00:13 | Li_Liu | let's wait for sundar for a bit | |
| 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:14 | 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 | wangzhh | Sundar, so one deployable can report 2 or more attach_handle? | |
| 03:16:27 | Coco_gao | Sundar, thank you. | |
| 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? | |