Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2019-01-16
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
03:53:54 openstack Meeting ended Wed Jan 16 03:53:52 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
03:53:55 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-01-16-03.04.html
03:53:56 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-01-16-03.04.txt
03:53:57 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-01-16-03.04.log.html
03:54:00 Sundar Good day, everybody
10:23:45 openstackgerrit Xinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects https://review.openstack.org/630579
10:41:18 openstackgerrit Xinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects https://review.openstack.org/630579
#openstack-cyborg - 2019-01-17
06:02:52 openstackgerrit lijunjie proposed openstack/cyborg master: Fix the misspelling of "search" https://review.openstack.org/631414
#openstack-cyborg - 2019-01-18
00:52:04 openstackgerrit YumengBao proposed openstack/cyborg master: Add new DB schema: sqlachemy and alembic scripts. https://review.openstack.org/625630
00:52:05 openstackgerrit YumengBao proposed openstack/cyborg master: Add Device and DeviceProfile objects https://review.openstack.org/631683
#openstack-cyborg - 2019-01-21
14:40:09 openstackgerrit coco-Gao proposed openstack/cyborg master: Add new DB schema: sqlachemy and alembic scripts. https://review.openstack.org/625630
15:23:38 openstackgerrit wangzhh proposed openstack/cyborg master: Add ExtArq and ARQ object https://review.openstack.org/630427
#openstack-cyborg - 2019-01-22
08:38:33 openstackgerrit zhouxinyong proposed openstack/cyborg master: Fix author-email in setup.cfg https://review.openstack.org/632307
08:39:51 openstackgerrit zhouxinyong proposed openstack/cyborg-specs master: Fix author-email in setup.cfg https://review.openstack.org/632308
11:54:41 openstackgerrit zhouxinyong proposed openstack/os-acc master: Fix author-email in setup.cfg https://review.openstack.org/632441
17:56:48 openstackgerrit wangzhh proposed openstack/cyborg master: Add ExtArq and ARQ object https://review.openstack.org/630427
#openstack-cyborg - 2019-01-23
03:00:26 Li_Liu HI GUys
03:01:25 Li_Liu I will wait for couple more min
03:03:18 yumeng Hi Li_Liu
03:03:22 Li_Liu #startmeeting openstack-cyborg
03:03:23 openstack Meeting started Wed Jan 23 03:03:22 2019 UTC and is due to finish in 60 minutes. The chair is Li_Liu. Information about MeetBot at http://wiki.debian.org/MeetBot.

Earlier   Later