| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-08-22 | |||
| 03:29:14 | Coco_gao_ | OK. | |
| 03:29:26 | Coco_gao_ | Agree that we should keep vendor ID | |
| 03:29:38 | xinranwang | each driver should know about the mapping relation between id and name, but cyborg-agent/conductor don't | |
| 03:30:11 | Sundar | The Cyborg driver for a vendor could even hardcode the vendor name, if it will handle only one vendor. | |
| 03:30:35 | xinranwang | So IMO, driver should report vendor name anyway. | |
| 03:30:54 | Sundar | xinranwang: Agreed. Proposal: Add vendor name to driver_objects.device . Any objections? | |
| 03:30:56 | wangzhh | Sundar, It is hardcoded in driver now. | |
| 03:31:08 | wangzhh | Agreed | |
| 03:31:26 | xinranwang | no objection. | |
| 03:31:45 | xinranwang | Btw, i find driver name in deployable tables, but no assignment. | |
| 03:32:04 | shaohe_feng | Yes， I translate the vendor ID to name for FPGA in my DEMO | |
| 03:32:05 | Coco_gao_ | Agree. The object.device will not add vendor name? Only driver_objects.device will? | |
| 03:32:54 | shaohe_feng | it can add a vendor name | |
| 03:33:24 | Sundar | Coco_gao_: Good point. It will be easier to add it to device object too, for use in ext-arq binding for creating traits | |
| 03:33:24 | shaohe_feng | but maybe more driver infos, such as driver version. | |
| 03:34:06 | Sundar | Do we need to add that to the db then? Oherwise, how how do we get it in the device object by querying? | |
| 03:34:07 | wangzhh | So just add name in object, not in db, right? | |
| 03:34:09 | Coco_gao_ | My question is do you think we should keep vendor name in object or database? | |
| 03:34:35 | shaohe_feng | for a long term. maybe we can translate the ID to name at present. | |
| 03:34:37 | shaohe_feng | DB | |
| 03:34:58 | Coco_gao_ | vendor ID is already in DB? | |
| 03:35:03 | xinranwang | Sundar: what is driver name you added in deployable table stand for? | |
| 03:35:22 | wangzhh | coco yep | |
| 03:35:27 | Sundar | If you don;t add the vendor name to db, the translation from id to name may have to be outside the driver too, which is not good | |
| 03:35:32 | xinranwang | Coco_gao_: yes, in device tables | |
| 03:36:09 | Yumeng | Coco_gao_:yes. already have vendor_id in db device table | |
| 03:36:42 | Coco_gao_ | About the ext-arq binding, do we need to qurey DB for vendor name? | |
| 03:36:44 | Sundar | xinranwang: It is the driver that is used for programming and device updates. At discovery time, we know which deployable has which driver. So, we can use that info to locate the driver needed for programming. | |
| 03:37:00 | shaohe_feng | https://github.com/shaohef/cyborg/commit/7e353bf09259a9b4cfba3763f3a99eb1adfaaa2b#diff-7ca60ed56d570ebe3490 | |
| 03:37:11 | xinranwang | Sundar: | |
| 03:37:20 | xinranwang | there is no assignment of this field | |
| 03:37:24 | Sundar | Coco_gao_: For ext_arq binding, we are queryig db for the deployable now. We can extend tthat to query the device and its vendor name too | |
| 03:37:38 | xinranwang | maybe we can extract vendor name from this field? | |
| 03:37:40 | shaohe_feng | here is what I do, just for a temporary solution | |
| 03:38:19 | shaohe_feng | driver_name = db_deployable.driver_name | |
| 03:39:44 | Sundar | xinranwang: The intention is that, when the agent discovers a device from a driver, it sends the driver name to the conductor and has it persisted. | |
| 03:40:39 | Sundar | shaohe_feng: That is what we are doing today. We could use the driver name and vendor name as same-- at least for Train. Is that what I am hearing from many of you? | |
| 03:41:24 | xinranwang | Sundar: so what will it look like? intel_fpga_driver? or 0x8086 like shaohe's demo does. | |
| 03:41:40 | shaohe_feng | https://github.com/shaohef/cyborg/blob/profile-ctrl/cyborg/accelerator/drivers/fpga/base.py#L23 | |
| 03:42:16 | shaohe_feng | for fpga driver, I maintain a map, both vendor ID and name can work. | |
| 03:42:40 | shaohe_feng | Sundar: yes, we need a driver name | |
| 03:43:17 | Sundar | xinranwang: just 'intel', for example. That is what we use to load a driver module. The intel_fpga_driver is the name in setup.cfg. | |
| 03:44:08 | xinranwang | so we should fill driver_name with 'intel' for example? | |
| 03:44:28 | xinranwang | if so, we can extract vendor name for driver_name.. | |
| 03:44:54 | Sundar | Yes, xinranwang. To summarize, I think we are agreeing to update the driver_name field in the deployable and use that as 'vendor name' to create the traits as per https://review.opendev.org/gitweb?p=openstack/cyborg-specs.git;f=specs/train/approved/cyborg-nova-placement.rst;hb=refs/changes/45/603545/7#l179 | |
| 03:45:02 | Sundar | Sounds good? | |
| 03:45:21 | Sundar | Then no need to add vendor_name to any object | |
| 03:45:44 | xinranwang | yes | |
| 03:46:56 | Sundar | Great. If others have objecttions, please LMK. Let's move on in the interest of time | |
| 03:47:04 | Sundar | #topic python cyborg client | |
| 03:47:44 | s_shogo | I'm working that with P5-P9 patch in advance. | |
| 03:48:12 | Sundar | Thanks, s_shogo. I am wondering if we have the time to update the cyborg client to v2 API? | |
| 03:48:28 | Coco_gao_ | So zhenghao's patch should use Vendor ID and then update deployable vendor name? | |
| 03:48:47 | Sundar | Coco_gao_: Yes | |
| 03:48:48 | Coco_gao_ | update to deployable table with vendor name | |
| 03:48:54 | Coco_gao_ | Sounds good. | |
| 03:49:21 | Sundar | It already has a driver name. At least today, driver name and vendor name are the same. | |
| 03:49:36 | Sundar | s_shogo: May be we need somebody to help you, for the client? | |
| 03:49:43 | s_shogo | Sundar : ok, I think so. I'll report the prospection for the v2 API Work in every IRC meeting. | |
| 03:50:12 | Sundar | s_shogo: Thanks a lot. Appreciate it. :) Please do ask if you need help. | |
| 03:50:49 | Sundar | BTW, TC has proposed: https://review.opendev.org/#/c/675317/ | |
| 03:50:50 | s_shogo | Sundar: Ok, Thanks. | |
| 03:51:25 | Sundar | They are proposing an intermediate release of the client. IMHO, it is useless because it is currently v1 based, has no Python 3 fixes and so nothing new from Stein release | |
| 03:51:47 | Sundar | We may as well club the client update with Train release. What do you al think? | |
| 03:53:47 | Sundar | Coco_gao_, wangzhh, xinranwang, shaohe_feng, Li_Liu, all: ^ | |
| 03:54:39 | Coco_gao_ | Agree if we have time. I don't know whether we can make that happen, are you optimistic about that? | |
| 03:54:51 | xinranwang | what's club mean.... | |
| 03:55:13 | Sundar | xinranwang: I mean combine client update with rest of Train release. | |
| 03:55:54 | Sundar | Coco_gao_: Yes, i share that concern. Once s_shogo lets us know if it can happen by Sep, we can decide. | |
| 03:56:25 | xinranwang | Yes, nice to have. | |
| 03:57:02 | Sundar | Yes, It will probably be lesser priority than Nova integ, Python 3, RBAC/security etc. Anybody thinks otherwise? | |
| 03:57:14 | Coco_gao_ | Agree. | |
| 03:57:33 | Sundar | #topic Other important Train tasks | |
| 03:57:48 | shaohe_feng | should the async bind in this release？ | |
| 03:58:04 | Sundar | wangzhh: Could you give us an update on RBAC, whenever you have the time? | |
| 03:58:21 | Sundar | shaohe_feng: Yes. It is needed for Nova integ | |
| 03:58:33 | xinranwang | I notice current code does not create deployable with driver_name, does it? Maybe need one patch on it? | |
| 03:58:41 | shaohe_feng | OK. | |
| 03:58:52 | Sundar | xinranwang: Yes, it is a gap | |
| 03:58:54 | shaohe_feng | Then we will add 2 more state for bind. | |
| 03:59:15 | shaohe_feng | ARQ_BIND_STARTED and ARQ_DELETING | |
| 03:59:23 | Sundar | BIND_STARTED is already being added in my patches | |
| 03:59:32 | Sundar | But I agree | |
| 03:59:33 | shaohe_feng | ARQ_INITIAL, ARQ_BIND_STARTED, ARQ_BOUND, ARQ_DELETING, ARQ_UNBOUND, ARQ_BIND_FAILED | |
| 03:59:59 | shaohe_feng | there will be 7 states | |
| 04:00:11 | shaohe_feng | Use “->” for transform , “X->” for can’t transform. | |
| 04:00:15 | shaohe_feng | TING X-> ARQ_BOUND | |
| 04:00:20 | shaohe_feng | ARQ_BIND_FAILED | |
| 04:00:26 | shaohe_feng | any comments on it? | |
| 04:00:28 | Sundar | Yes. Between bind and unbind, making bind async is more important. We don;t do much in unbind today | |
| 04:00:34 | xinranwang | Sundar: I can help on it. I will submit a patch by today to fix that. | |
| 04:00:53 | Sundar | xinranwan: Excellent. Thanks :) | |
| 04:00:56 | shaohe_feng | ^ Sundar Coco_gao_ xinranwang wangzhh Yumeng | |
| 04:01:09 | xinranwang | Sundar: np | |
| 04:01:10 | Sundar | shaohe_feng: I agree | |
| 04:01:10 | Coco_gao_ | We'd better merge the old patch P5-P9 first, and then discuss what are the states? | |
| 04:01:36 | Coco_gao_ | Maybe a new patch for states update? | |
| 04:02:17 | Sundar | I think shaohe_fend will propose a new patch for async un/bind | |
| 04:02:25 | Sundar | *shaohe_feng | |
| 04:02:31 | Coco_gao_ | That's good. | |