| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-02-27 | |||
| 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? | |
| 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:21 | 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 | |
| 03:37:51 | openstack | Meeting ended Wed Feb 27 03:37:49 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 03:37:52 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-02-27-03.02.html | |
| 03:37:53 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-02-27-03.02.txt | |
| 03:37:54 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-02-27-03.02.log.html | |
| 03:46:31 | openstackgerrit | Yongjun Bai proposed openstack/cyborg master: Fix:add python-glanceclient for cyborg https://review.openstack.org/639487 | |
| 03:53:36 | openstackgerrit | Yongjun Bai proposed openstack/cyborg master: Fix:add python-glanceclient for cyborg https://review.openstack.org/639487 | |