03:04:40 #startmeeting openstack-cyborg 03:04:41 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:04:44 The meeting name has been set to 'openstack_cyborg' 03:04:53 #topic Roll Call 03:05:22 #nfo Sundar 03:05:27 #info Li_Liu 03:05:29 #info Yumeng 03:05:35 #info Sundar 03:05:57 #info jiapei 03:06:33 #topic DB work status 03:06:51 #info xinranwang 03:06:55 Thanks zhenghao for creating the task assignment in #link https://storyboard.openstack.org/#!/story/2004248 03:07:33 #info shaohe 03:07:36 There are a few commits for these tasks 03:07:54 please help review if you have chance 03:08:15 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 model VARCHAR2 (255 BYTE) /*Device model*/ 03:08:43 this one 03:08:45 ? 03:08:48 Li_Liu: what's model should be like? 03:09:22 yes, is it a json? 03:09:45 what should be include in it? 03:10:12 Sundar, could you help to explain? 03:10:55 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 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 ok, thanks 03:13:46 Also, you can look at the initial_setup.sh script in the pilot branch 03:14:04 https://review.openstack.org/#/c/626420 03:15:19 OK. Cool! 03:16:27 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 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 Have any of you been able to deploy the code from the pilot branch and check out the curl commands? 03:16:45 the key factors 03:16:57 should we keep project_id in some object fields, or just do not implement it for now ? 03:17:10 Hi all, 03:17:15 #info Coco_gao 03:17:52 Hi CoCo 03:17:55 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 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 Sundar: ok. Then I will discuss with my colleague to see what might be included. 03:19:46 Sundar, I guess the device drivers can leverage that right? 03:20:09 xinranwang: Good question. For RBAC checking in API, we don't need that, right? 03:20:48 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 alright, any one has any other question regarding the DB work? 03:23:03 about the attachhandle 03:23:28 is that connect to "device_id" or "deployable_id"? 03:23:37 have you discussed about that 03:24:01 Coco_gao: We had an email thread about that in Nov/Dec, right? 03:24:59 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 For the type of devices we have now, we can do it either way. 03:26:46 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 I recall that thread 03:27:13 Hi all, sorry for I'm late. 03:27:23 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 Sundar: so the quota will also be implemented in API. 03:27:43 it's ok, we are discussing the DB tasks you assigned 03:28:21 xinranwang: for quotas, can we not use Keystone unified limits? 03:28:55 Coco_gao,Sundar,Li_Liu : Can any of you share that eamil with me ? 03:28:56 yes, i mean quota usage 03:29:17 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 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 xinranwang: If Keystone implements limits, can you clarify why you need project id in our tables? 03:35:50 Sundar, I remember the decision we made was go with deployable_id for now 03:38:24 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 Sundar: keystone just manage quota limit, every service should manage their own quota usage 03:39:00 Let's use the deployable_id then. Yumeng 03:41:40 Coco_gao, we will use deployable_id for now 03:42:03 Let's move on 03:42:11 Li_Liu: ok. please go on. 03:42:15 OK, I got that, i will resubmit my patch. 03:42:33 #topic Sundar's pilot branch status 03:42:52 Sundar, thanks for the efforts again 03:43:06 I will try out the apis 03:43:27 could you also send a short readme on how to use the API in pilot branch? 03:44:48 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 ah ok 03:45:03 Esp. nova-integ/README 03:45:35 The main thing to note is that, in the absence of os-acc, cyborg client is providing an interface to Nova 03:45:58 That cannot change even if the human-readable output needs to change. That drivers some decisions 03:46:03 *drives 03:47:04 that should be fine for now 03:47:18 one question tho 03:48:01 how much difference is the nova side change between using future master branch and the pilot branch? 03:48:21 just the nova side change specifically 03:49:08 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 That way, whatever the Nova folks review is what gets implemented 03:50:11 that's good to know 03:51:17 ok, next topic 03:51:33 #topic AoB 03:52:03 any other business 03:52:55 Otherwise, let's call it 03:53:07 Thanks guys for the effort 03:53:36 Have a good day/night where ever you are :) 03:53:41 Thanks bye. see you next time 03:53:52 #endmeeting