Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2019-08-22
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.
04:02:38 Sundar wangzhh: Can you please let us know about RBAC?
04:02:50 xinranwang btw, please review this https://review.opendev.org/#/c/677436/ when you got time :)
04:02:51 shaohe_feng Yes. After discussion, I should also implement the code. So I'm afraid there is no time left for me
04:02:54 Coco_gao_ maybe he is offline
04:03:08 wangzhh Test in my local env
04:03:13 shaohe_feng we should discuss it ASAP
04:03:31 Coco_gao_ you can arrange a meeting to discuss that.
04:03:41 wangzhh probably submit patch tomorrow
04:03:42 shaohe_feng any comments on the states transform above?
04:04:03 Sundar shaohe_feng: I agree with your states. I think they will suffice. Let's start with them and have people code review it?
04:04:05 shaohe_feng ^ Sundar Coco_gao_ xinranwang wangzhh Yumeng
04:04:37 Sundar I will also prioritize it for next week's IRC call
04:04:41 Coco_gao_ As good as my expectation, thank you.
04:05:03 Sundar Hopefully, P5-P9 patches would have merged by then :)
04:05:21 Yumeng shaohe_feng: no objections ^^
04:05:30 Coco_gao_ Let's set a deadline for P5-P9 reviews?
04:05:30 Sundar #topic AoB
04:05:46 Sundar Coco_gao_: That would be welcome!
04:05:51 wangzhh shaohe no objections

Earlier   Later