| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-02-27 | |||
| 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 | |
| 03:56:30 | openstackgerrit | Yongjun Bai proposed openstack/cyborg master: Fix:add python-glanceclient for cyborg https://review.openstack.org/639487 | |
| 04:34:04 | openstackgerrit | Yongjun Bai proposed openstack/cyborg master: Fix:add python-glanceclient for cyborg https://review.openstack.org/639487 | |
| 05:02:57 | openstackgerrit | coco-Gao proposed openstack/cyborg master: Add New Driver OVO. https://review.openstack.org/624138 | |
| 07:43:38 | openstackgerrit | Merged openstack/cyborg master: Add OS-limitation in the devstack_setup doc https://review.openstack.org/627613 | |
| 07:43:43 | openstackgerrit | Merged openstack/cyborg master: Replacing the HTTP protocal with HTTPS in devstack_setup.rst. https://review.openstack.org/617778 | |
| 09:31:17 | openstackgerrit | Yongjun Bai proposed openstack/cyborg master: Fix:add python-glanceclient to cyborg requirements https://review.openstack.org/639487 | |
| 09:40:21 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Bug fix: Associate controlpath with device_id https://review.openstack.org/639610 | |
| 09:51:09 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Bug fix: Associate controlpath with device_id https://review.openstack.org/639610 | |
| 11:05:28 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Bug fix: Change object definition according to the newest DB. https://review.openstack.org/639610 | |
| 14:32:53 | openstackgerrit | Merged openstack/cyborg master: Bug fix: Change object definition according to the newest DB. https://review.openstack.org/639610 | |
| 15:16:43 | efried | cdent: o/ | |
| 15:16:47 | cdent | hola | |
| 15:17:06 | efried | Since Berlin, Sundar has been working hard to put together a PoC series for the cyborg/nova interaction | |
| 15:17:22 | efried | including writing the v2.0 APIs in cyborg itself | |
| 15:17:43 | efried | We wrote up an etherpad with a summary of the APIs that are used in the Poc | |
| 15:18:10 | efried | and were hoping to get some API-oriented eyeballs on it to make sure there aren't any egregious violations of overall stylisticness or OpenStack APIness. | |
| 15:18:23 | efried | would you be willing to help out there? | |
| 15:18:24 | Sundar | o/, cdent and efried | |
| 15:18:41 | efried | Not looking for a detailed review, and not of the source code, just of the interfaces | |