Wednesday, 2019-01-16

*** TxGirlGeek has quit IRC01:52
*** Sundar has joined #openstack-cyborg02:43
*** Li_Liu has joined #openstack-cyborg02:50
*** Yumeng has joined #openstack-cyborg02:57
*** xinranwang has joined #openstack-cyborg02:59
Li_LiuHi guys03:01
*** HongboZhao has joined #openstack-cyborg03:02
xinranwangHi Li_Liu03:02
Li_LiuLet's wait for couple more min03:03
*** shaohe_feng_ has joined #openstack-cyborg03:03
shaohe_feng_#info shaohe03:04
shaohe_feng_good night Li_Liu03:04
Li_Liu#startmeeting openstack-cyborg03:04
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.03:04
*** openstack changes topic to " (Meeting topic: openstack-cyborg)"03:04
openstackThe meeting name has been set to 'openstack_cyborg'03:04
Li_Liu#topic Roll Call03:04
*** openstack changes topic to "Roll Call (Meeting topic: openstack-cyborg)"03:04
Sundar#nfo Sundar03:05
Li_Liu#info Li_Liu03:05
Yumeng#info Yumeng03:05
Sundar#info Sundar03:05
jiapei#info jiapei03:05
Li_Liu#topic DB work status03:06
*** openstack changes topic to "DB work status (Meeting topic: openstack-cyborg)"03:06
xinranwang#info xinranwang03:06
Li_LiuThanks zhenghao for creating the task assignment in #link!/story/200424803:06
shaohe_feng_#info shaohe03:07
Li_LiuThere are a few commits for these tasks03:07
Li_Liuplease help review if you have chance03:07
*** changzhi has joined #openstack-cyborg03:08
YumengLi_Liu: I have a question about the device table.  Line 16903:08
Li_Liumodel             VARCHAR2 (255 BYTE)    /*Device model*/03:08
Li_Liuthis one03:08
YumengLi_Liu: what's model should be like?03:08
Yumengyes, is it a json?03:09
*** changzhi_ has joined #openstack-cyborg03:09
Yumengwhat should be include in it?03:09
Li_LiuSundar, could you help to explain?03:10
SundarThe model name is intended to provide Cyborg with a way to derive the Device Family trait for Placement:
SundarSo, 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 value03:11
*** changzhi has quit IRC03:12
Yumengok, thanks03:13
SundarAlso, you can look at the script in the pilot branch03:13
YumengOK. Cool!03:15
YumengSundar: also  about the std_board_info, vendor_board_info of a device. what are a key factors should be included in them ?03:16
Li_Liuregarding 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 stuff03:16
SundarHave any of you been able to deploy the code from the pilot branch and check out the curl commands?03:16
Yumengthe key factors03:16
xinranwangshould we keep project_id in some object fields, or just do not implement it for now ?03:16
*** Coco_gao has joined #openstack-cyborg03:17
Coco_gaoHi all,03:17
Coco_gao#info Coco_gao03:17
Li_LiuHi CoCo03:17
SundarYumeng: 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:17
SundarOne would think that flash memory size, BMC version etc. can be included here. But you are all welcome to provide your input03:18
YumengSundar: ok. Then I will discuss with my colleague to see what might be included.03:19
Li_LiuSundar, I guess the device drivers can leverage that right?03:19
Sundarxinranwang: Good question. For RBAC checking in API, we don't need that, right?03:20
SundarLi_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:20
Li_Liualright, any one has any other question regarding the DB work?03:22
Coco_gaoabout the attachhandle03:23
Coco_gaois that connect to "device_id" or "deployable_id"?03:23
Coco_gaohave you discussed about that03:23
SundarCoco_gao: We had an email thread about that in Nov/Dec, right?03:24
SundarWhichever way we go, there may be some category of devices in the future which doesn't fit that but needs the other way03:24
SundarFor the type of devices we have now, we can do it either way.03:25
*** wangzhh has joined #openstack-cyborg03:26
SundarPlease 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
Li_LiuI recall that thread03:26
wangzhhHi all, sorry for I'm late.03:27
SundarSo, 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
xinranwangSundar:  so the quota will also be implemented in API.03:27
Li_Liuit's ok, we are discussing the DB tasks you assigned03:27
Sundarxinranwang: for quotas, can we not use Keystone unified limits?03:28
YumengCoco_gao,Sundar,Li_Liu : Can any of you share that eamil with me ?03:28
xinranwangyes, i mean quota usage03:28
YumengI 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:29
SundarYumeng: 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 now03:31
Sundarxinranwang: If Keystone implements limits, can you clarify why you need project id in our tables?03:32
Li_LiuSundar, I remember the decision we made was go with deployable_id for now03:35
SundarLi_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 future03:38
*** HongboZhao has quit IRC03:38
xinranwangSundar:  keystone just manage quota limit, every service should manage their own quota usage03:38
Li_LiuLet's use the deployable_id then. Yumeng03:39
Li_LiuCoco_gao, we will use deployable_id for now03:41
Li_LiuLet's move on03:42
YumengLi_Liu: ok. please go on.03:42
Coco_gaoOK, I got that, i will resubmit my patch.03:42
Li_Liu#topic Sundar's pilot branch status03:42
*** openstack changes topic to "Sundar's pilot branch status (Meeting topic: openstack-cyborg)"03:42
Li_LiuSundar, thanks for the efforts again03:42
Li_LiuI will try out the apis03:43
Li_Liucould you also send a short readme on how to use the API in pilot branch?03:43
SundarLi_Liu: The comit message of gives a short description and points to 2 other READMEs.03:44
Li_Liuah ok03:45
SundarEsp. nova-integ/README03:45
SundarThe main thing to note is that, in the absence of os-acc, cyborg client is providing an interface to Nova03:45
SundarThat cannot change even if the human-readable output needs to change. That drivers some decisions03:45
Li_Liuthat should be fine for now03:47
Li_Liuone question tho03:47
Li_Liuhow much difference is the nova side change between using future master branch and the pilot branch?03:48
Li_Liujust the nova side change specifically03:48
SundarAh, 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
SundarThat way, whatever the Nova folks review is what gets implemented03:49
Li_Liuthat's good to know03:50
Li_Liuok, next topic03:51
Li_Liu#topic AoB03:51
*** openstack changes topic to "AoB (Meeting topic: openstack-cyborg)"03:51
Li_Liuany other business03:52
Li_LiuOtherwise, let's call it03:52
Li_LiuThanks guys for the effort03:53
Li_LiuHave a good day/night where ever you are :)03:53
YumengThanks bye. see you next time03:53
*** openstack changes topic to "Pending patches (Meeting topic: openstack-cyborg)"03:53
openstackMeeting ended Wed Jan 16 03:53:52 2019 UTC.  Information about MeetBot at . (v 0.1.4)03:53
openstackMinutes (text):
SundarGood day, everybody03:54
*** Li_Liu has quit IRC03:55
*** Sundar has quit IRC03:58
*** sum12 has quit IRC04:54
*** sum12 has joined #openstack-cyborg05:06
*** changzhi_ has quit IRC05:40
*** wangzhh has quit IRC06:05
*** xinranwang has quit IRC06:08
*** TxGirlGeek has joined #openstack-cyborg06:34
*** TxGirlGeek has quit IRC06:40
*** Yumeng has quit IRC08:39
*** shaohe_feng_ has quit IRC08:52
*** Coco_gao has quit IRC09:16
*** openstackgerrit has joined #openstack-cyborg10:23
openstackgerritXinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects
openstackgerritXinran WANG proposed openstack/cyborg master: Add AttachHandle and ControlpathID objects
*** helenafm has joined #openstack-cyborg11:13
*** davidsha has joined #openstack-cyborg14:10
*** TxGirlGeek has joined #openstack-cyborg15:58
*** helenafm has quit IRC17:47
*** davidsha has quit IRC17:49
*** efried has quit IRC19:04
*** efried has joined #openstack-cyborg19:21
*** TxGirlGeek has quit IRC20:06
*** TxGirlGeek has joined #openstack-cyborg20:10
*** TxGirlGeek has quit IRC20:45
*** TxGirlGeek has joined #openstack-cyborg20:57
*** TxGirlGeek has quit IRC21:21
*** TxGirlGeek has joined #openstack-cyborg21:31
*** TxGirlGeek has quit IRC23:07
*** TxGirlGeek has joined #openstack-cyborg23:12
*** efried has quit IRC23:30
*** efried has joined #openstack-cyborg23:43

Generated by 2.15.3 by Marius Gedminas - find it at!