03:04:40 <Li_Liu> #startmeeting openstack-cyborg
03:04:41 <openstack> Meeting started Wed Jan 16 03:04:40 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:04:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:04:44 <openstack> The meeting name has been set to 'openstack_cyborg'
03:04:53 <Li_Liu> #topic Roll Call
03:05:22 <Sundar> #nfo Sundar
03:05:27 <Li_Liu> #info Li_Liu
03:05:29 <Yumeng> #info Yumeng
03:05:35 <Sundar> #info Sundar
03:05:57 <jiapei> #info jiapei
03:06:33 <Li_Liu> #topic DB work status
03:06:51 <xinranwang> #info xinranwang
03:06:55 <Li_Liu> Thanks zhenghao for creating the task assignment in #link  https://storyboard.openstack.org/#!/story/2004248
03:07:33 <shaohe_feng_> #info shaohe
03:07:36 <Li_Liu> There are a few commits for these tasks
03:07:54 <Li_Liu> please help review if you have chance
03:08:15 <Yumeng> Li_Liu: I have a question about the device table. https://review.openstack.org/#/c/615462/9/specs/stein/approved/cyborg-database-model-proposal.rst  Line 169
03:08:40 <Li_Liu> model             VARCHAR2 (255 BYTE)    /*Device model*/
03:08:43 <Li_Liu> this one
03:08:45 <Li_Liu> ?
03:08:48 <Yumeng> Li_Liu: what's model should be like?
03:09:22 <Yumeng> yes, is it a json?
03:09:45 <Yumeng> what should be include in it?
03:10:12 <Li_Liu> Sundar, could you help to explain?
03:10:55 <Sundar> The model name is intended to provide Cyborg with a way to derive the Device Family trait for Placement: https://git.openstack.org/cgit/openstack/cyborg-specs/tree/specs/stein/approved/cyborg-nova-placement.rst?h=refs/changes/45/603545/4#n150
03:11:52 <Sundar> So, an example value for model would be 'Arria 10 PAC'. Together with vendor name 'Intel' and device type 'FPGA', this will give the full trait value
03:13:19 <Yumeng> ok, thanks
03:13:46 <Sundar> Also, you can look at the initial_setup.sh script in the pilot branch
03:14:04 <Sundar> https://review.openstack.org/#/c/626420
03:15:19 <Yumeng> OK. Cool!
03:16:27 <Yumeng> Sundar: also  about the std_board_info, vendor_board_info of a device. what are a key factors should be included in them ?
03:16:37 <Li_Liu> regarding the tasks assignments, do you guys have any questions/concerns so far? I hope we can land them by the end of this month. So that we can let the drive team rewrite their stuff
03:16:38 <Sundar> Have any of you been able to deploy the code from the pilot branch and check out the curl commands?
03:16:45 <Yumeng> the key factors
03:16:57 <xinranwang> should we keep project_id in some object fields, or just do not implement it for now ?
03:17:10 <Coco_gao> Hi all,
03:17:15 <Coco_gao> #info Coco_gao
03:17:52 <Li_Liu> Hi CoCo
03:17:55 <Sundar> Yumeng: The std_board_info is expected to include properties that Cyborg will standardize, whereas vendor_board_info is all custom attributes. We have not decided on a formal lost of what should be standardized.
03:18:27 <Sundar> One would think that flash memory size, BMC version etc. can be included here. But you are all welcome to provide your input
03:19:18 <Yumeng> Sundar: ok. Then I will discuss with my colleague to see what might be included.
03:19:46 <Li_Liu> Sundar, I guess the device drivers can leverage that right?
03:20:09 <Sundar> xinranwang: Good question. For RBAC checking in API, we don't need that, right?
03:20:48 <Sundar> Li_Liu: Device drivers should provide that. Then an operator can run queries on Cyborg API like, 'how many devices have BMC version older than 1.5'
03:22:51 <Li_Liu> alright, any one has any other question regarding the DB work?
03:23:03 <Coco_gao> about the attachhandle
03:23:28 <Coco_gao> is that connect to "device_id" or "deployable_id"?
03:23:37 <Coco_gao> have you discussed about that
03:24:01 <Sundar> Coco_gao: We had an email thread about that in Nov/Dec, right?
03:24:59 <Sundar> Whichever way we go, there may be some category of devices in the future which doesn't fit that but needs the other way
03:25:23 <Sundar> For the type of devices we have now, we can do it either way.
03:26:46 <Sundar> Please note that, for some devices, there will be only one PCI function (no SR-IOV), so that will be both the controlath_id (like PF) and also an attach handle (like VF)
03:26:50 <Li_Liu> I recall that thread
03:27:13 <wangzhh> Hi all, sorry for I'm late.
03:27:23 <Sundar> So, since controlpath_ids go with devices, I thought it is best to keep attach handles also there. But we can do it either way.
03:27:39 <xinranwang> Sundar:  so the quota will also be implemented in API.
03:27:43 <Li_Liu> it's ok, we are discussing the DB tasks you assigned
03:28:21 <Sundar> xinranwang: for quotas, can we not use Keystone unified limits?
03:28:55 <Yumeng> Coco_gao,Sundar,Li_Liu : Can any of you share that eamil with me ?
03:28:56 <xinranwang> yes, i mean quota usage
03:29:17 <Yumeng> I was thinking One device may have too many AttachHandles while less AttachHandles are derived from one "deployable_id". If we keep device_id, we may have lots of attach handles sharing one same device_id.  IMHO, we should keep "deployable_id" here just like that in the Attribute Table.
03:31:26 <Sundar> Yumeng: What kind of device do you have in mind? Coco/Zhenghao are working on Nvidia GPU driver as physical GPU, so no SR-IOV, just one PCI function. For the Intel and other FPGAs I konow about, we have just one PF and one VF for now
03:32:07 <Sundar> xinranwang: If Keystone implements limits, can you clarify why you need project id in our tables?
03:35:50 <Li_Liu> Sundar, I remember the decision we made was go with deployable_id for now
03:38:24 <Sundar> Li_Liu: I recall otherwise :). But no issues, if the community wants to go with deployable id, let's do that, with the proviso that we _might_ have to change that sometime in the future
03:38:55 <xinranwang> Sundar:  keystone just manage quota limit, every service should manage their own quota usage
03:39:00 <Li_Liu> Let's use the deployable_id then. Yumeng
03:41:40 <Li_Liu> Coco_gao, we will use deployable_id for now
03:42:03 <Li_Liu> Let's move on
03:42:11 <Yumeng> Li_Liu: ok. please go on.
03:42:15 <Coco_gao> OK, I got that, i will resubmit my patch.
03:42:33 <Li_Liu> #topic Sundar's pilot branch status
03:42:52 <Li_Liu> Sundar, thanks for the efforts again
03:43:06 <Li_Liu> I will try out the apis
03:43:27 <Li_Liu> could you also send a short readme on how to use the API in pilot branch?
03:44:48 <Sundar> Li_Liu: The comit message of https://review.openstack.org/#/c/626420/ gives a short description and points to 2 other READMEs.
03:45:01 <Li_Liu> ah ok
03:45:03 <Sundar> Esp. nova-integ/README
03:45:35 <Sundar> The main thing to note is that, in the absence of os-acc, cyborg client is providing an interface to Nova
03:45:58 <Sundar> That cannot change even if the human-readable output needs to change. That drivers some decisions
03:46:03 <Sundar> *drives
03:47:04 <Li_Liu> that should be fine for now
03:47:18 <Li_Liu> one question tho
03:48:01 <Li_Liu> how much difference is the nova side change between using future master branch and the pilot branch?
03:48:21 <Li_Liu> just the nova side change specifically
03:49:08 <Sundar> Ah, ideally, none. The API interfaces should remain the same when we move it to master branch from pilot branch. Some implementation details may change (e.g. add RBAC)
03:49:26 <Sundar> That way, whatever the Nova folks review is what gets implemented
03:50:11 <Li_Liu> that's good to know
03:51:17 <Li_Liu> ok, next topic
03:51:33 <Li_Liu> #topic AoB
03:52:03 <Li_Liu> any other business
03:52:55 <Li_Liu> Otherwise, let's call it
03:53:07 <Li_Liu> Thanks guys for the effort
03:53:36 <Li_Liu> Have a good day/night where ever you are :)
03:53:41 <Yumeng> Thanks bye. see you next time
03:53:52 <Li_Liu> #endmeeting