| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-01-12 | |||
| 08:20:49 | openstackgerrit | wangzhh proposed openstack/cyborg master: Add ExtArq object https://review.openstack.org/630427 | |
| #openstack-cyborg - 2019-01-14 | |||
| 03:25:07 | openstackgerrit | Andriy Shevchenko proposed openstack/os-acc master: Change openstack-dev to openstack-discuss https://review.openstack.org/622443 | |
| 05:50:42 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Add new DB schema: sqlachemy and alembic scripts. https://review.openstack.org/625630 | |
| 05:50:42 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects https://review.openstack.org/630579 | |
| 05:52:44 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects https://review.openstack.org/630579 | |
| 10:48:56 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects https://review.openstack.org/630579 | |
| 11:00:34 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects https://review.openstack.org/630579 | |
| #openstack-cyborg - 2019-01-15 | |||
| 02:42:14 | openstackgerrit | Merged openstack/cyborg master: Fix tox -e py27 https://review.openstack.org/628386 | |
| #openstack-cyborg - 2019-01-16 | |||
| 03:01:47 | Li_Liu | Hi guys | |
| 03:02:43 | xinranwang | Hi Li_Liu | |
| 03:02:51 | Sundar | Hi | |
| 03:03:24 | Li_Liu | Let's wait for couple more min | |
| 03:04:12 | shaohe_feng_ | #info shaohe | |
| 03:04:26 | shaohe_feng_ | good night Li_Liu | |
| 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) | |