Wednesday, 2018-09-26

*** helenafm has joined #openstack-cyborg07:31
*** fanzhang_ has joined #openstack-cyborg08:33
fanzhang_zhipeng hi, I've read about your mail about zero tolerance policy on padding activities, thanks for pointing it out. Yes, it's exactly what I've been confused with. Many Chinese developers could do better that just commit such patches. I talked about this with one contributor in patch And how can I join the wechat group?08:35
zhipengThanks fan :) you could add me by searching y cell number 1857665896608:37
zhipengI can pull you in :)08:37
fanzhang_thanks so mucn08:37
zhipengNo problem :)08:37
*** jaypipes has joined #openstack-cyborg11:17
*** Coco_gao has joined #openstack-cyborg14:02
Coco_gaoHi all14:02
Coco_gaoGood night or  good morning~14:02
*** Li_Liu has joined #openstack-cyborg14:03
Li_LiuHI Guys14:03
*** xinran has joined #openstack-cyborg14:04
Li_Liu#startmeeting openstack-cyborg14:05
openstackMeeting started Wed Sep 26 14:05:13 2018 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.14:05
*** openstack changes topic to " (Meeting topic: openstack-cyborg)"14:05
openstackThe meeting name has been set to 'openstack_cyborg'14:05
Coco_gao#info Coco_gao14:05
Li_Liu#topic Roll Call14:05
*** openstack changes topic to "Roll Call (Meeting topic: openstack-cyborg)"14:05
Li_Liu#info Li_Liu14:05
Li_LiuWho else do we have14:06
sum12#info sum1214:07
Li_LiuHi Xinran14:07
Li_LiuIs Sandar around?14:07
xinran#info xinran14:07
Li_LiuI was hoping to discuss some nova related question with him14:08
Li_Liu#topic post-ptg work items14:08
*** openstack changes topic to "post-ptg work items (Meeting topic: openstack-cyborg)"14:08
Li_LiuCoco, how is the DB evolution going?14:09
Coco_gaoSince we have VARs discussed in PTG, we still need VAR table.14:10
xinranI have looked into ptg summary, we will support a device profile in this release?14:10
Li_Liuwhat's the dependency for VAR?14:10
Coco_gaowe need to support dev_profile in Stein14:10
Li_Liudoes it involve nova folks?14:10
Coco_gaonova only use VARs, and will update VARs' status by calling os-acc, I think14:11
xinranwhat is VAR14:12
Coco_gaoWe should have a discuss on what field still remained and what else should be removed as well as the new table field14:12
Li_LiuDo you and XiaoHei need any help with this?14:13
Coco_gaowe may need Sundar's help on VAR table14:14
*** wangzhh has joined #openstack-cyborg14:14
xinranwhat is VAR ?14:15
Coco_gaoI think I can make a draft then we can discuss it together, Since Sundar wrote the recent Specs on device discovery and interactions with nova, he may have some advice I think.14:16
Coco_gaoVirtual Accelerator Record (VAR)14:16
xinranCoco_gao: thanks,14:17
Li_Liuok, Sundar is busy with his specs right now most likely14:17
Li_LiuI will talk with him and see how to balance his work14:17
xinranSeems there will be a changement at  db layer?14:18
Li_LiuI have a feeling we have too much work depend on him right now14:18
Li_Liuxinran, yes.14:18
Coco_gaoYes I think so, because he wrote the specs14:19
xinranLi_Liu:  could you please elaborate it or is there any docs concerning that?14:19
wangzhhYeap, most of specs.14:19
Coco_gaoWe should follow the spec right?14:20
Li_LiuRegarding the db change, I think Coco_gao is still drafting it14:21
Li_Liubut the you can find related information here:
Coco_gaoBut I and xiaohe talked to Sundar that he should not write the implementation details on his spec. Who write the code decide the details14:21
Li_LiuCoco_gao, thist's the right way14:22
Li_LiuOk, move on.14:23
sum12Li_Liu: were there any notes taken during the discussion with neutron team during PTG?14:23
Li_Liusum12, there are some notes here14:24
Coco_gaosum12, also
Li_LiuI saw Xinran is have 4 patches waiting :P14:26
Li_LiuI will take a look and provide comments14:26
sum12thanks Cato_gao14:26
Li_Liuhope to clear them up soon14:26
xinranLi_Liu:  thank14:26
xinranAnd I will submit another patch of os-acc soon14:27
Li_LiuI am still working on FPGA programming api. Just solve the glance client problem should provide a updated patch some within the week14:27
Li_Liuxinran, you are our super hero right now~~14:27
xinranAbout parse the flavor.extra_spec to the acceptable format to cyborg api14:28
xinranLi_Liu:  lol14:28
xinranBut these patches still need ovo land first14:28
Li_Liuright, you might need to sync up with Coco and Xiaohei for that14:29
Li_LiuCoco_gao wangzhh14:30
xinranLi_Liu:  yes, I have pull their patch to local and tested14:30
Coco_gaothe DB evolution is a huge change if we merge two tables(accelerators and deployables) as Sundar's suggest. Should we keep the old one?14:30
wangzhh:) Xiaohei...14:30
wangzhhGot it.14:30
Coco_gaoand evolve to the new version?14:31
wangzhhAgree. I suggest keep the old one now.14:32
Coco_gaoeverything will be changed after db evolution, the ovo,  my patch on device object should also be rewritten.14:33
Li_LiuI agree, let's keep the old one and decide when to remove it later14:34
xinranThe old one is the current one?14:35
wangzhhCoco, not really. Most of them can be reused. And we should hava a quick start.14:35
xinranI mean acc dep these 2 tables14:35
xinranOk, but my placement repot patch depends on ovo now14:38
Li_Liuok, I think we are clear on the work item and their dependencies14:42
Li_LiuLet's do this :)14:42
Li_Liu#topic AoB14:43
*** openstack changes topic to "AoB (Meeting topic: openstack-cyborg)"14:43
Coco_gaoIf we don't merge the two tables, then DB evolution is not urgent. Maybe I can do something more urgent right now.14:44
Li_LiuCoco_gao, I think xinran is worried if she's implementing based on old DB design, once you new DB is merged, she might have to rewrite the code over again14:46
*** helenafm has quit IRC14:47
Coco_gaoI think so, not only xinran's code.14:47
Coco_gaowe  finish rocky's target first?14:47
xinranMy code is now based on coco’s ovo patch :)14:48
Li_Liui see14:48
Coco_gaoAny feedback pls contact me directly, thanks xinran14:49
Li_LiuCoco_gao, yes, try to finish up R's left over first14:49
xinranSo I think it’s ok for me if we use ovo design14:49
Coco_gaoI think the urgent thing is the docs~~14:51
Li_Liualright, let's wrap up.14:51
Li_LiuCoco_gao I will work with Sundar on that to speed it up14:51
Coco_gaoI can join from this week, feel free to contact me if I can help.14:52
Li_Liuthanks Coco14:52
Li_Liuhave a night night guys14:52
*** openstack changes topic to "A zuul config error slipped through and caused a pile of job failures with retry_limit - a fix is being applied and should be back up in a few minutes"14:53
wangzhhInstallation guide is urgent.14:53
openstackMeeting ended Wed Sep 26 14:52:59 2018 UTC.  Information about MeetBot at . (v 0.1.4)14:53
openstackMinutes (text):
*** Li_Liu has quit IRC14:54
*** munimeha1 has joined #openstack-cyborg15:45
*** xinran has quit IRC17:02
*** Coco_gao has quit IRC17:11
*** wangzhh has quit IRC17:23
*** Sundar has joined #openstack-cyborg19:33
Sundarefried: Please ping me when you can19:33
efriedSundar: Hi there.19:38
SundarHi Eric, in the nova spec 603955, you said that having Cyborg claim a device by default (without explicit whitelisting) is a security risk. Can you elaborate?19:42
SundarLine 108 in
Sundar@efried: I'll be around for another 90 minutes. I'll step out after that and should be back by 5 pm PDT.20:26
efriedsorry I missed your response earlier. ffr best to tag me20:27
efriedNot claiming, but exposing20:27
efriedIf you expose, say, the controller that's handling the root disk of the management partition, and someone manages to attach it to the VM, your end user (the owner of the VM) could wreak havoc.20:28
efriedSundar: ^^ :)20:28
SundarAh, yes, will make sure to tag you :)20:29
Sundarefried: My statement was "if the operator has installed and configured Cyborg drivers, he has explicitly enabled the devices managed by those drivers."20:30
SundarWhy is that a security risk?20:30
efriedSundar: that should be fine.20:31
efriedstrike that.20:31
Sundarefried: NP. Will respond in the spec. Thanks.20:31
efriedSundar: as worded, it implies that by installing cyborg, you've enabled the devices20:32
efriedSundar: Is the "and configured" part where I would list which devices I wanted cyborg to manage?20:32
SundarWell, "installed Cyborg drivers". Installing a driver is a dleiberate act, right?20:33
efriedYes. But installing a driver capable of handling X does *not* mean that I want *all* instances of X to be handled by cyborg and made available for attachment to VMs.20:33
SundarI don't follow why that is a security risk. You may want to disable some, but that could be an explicit blacklist20:34
SundarIf the admin doesn't want all those devices, why would he install them?20:35
efriedI'm no expert, but that's not how security works.20:36
SundarIf some of those devices come pre-installed in the physical servers, like built-in NICs, I can understand.20:37
SundarI don;t think GPUs are pre-installed in data center class servers. (Desktops are a different story)20:37
*** edmondsw has joined #openstack-cyborg20:39
efriedSundar: I think it's less of a matter of what's *likely* to happen, and more about it just being a bad policy in general.20:39
efriededmondsw: you're a security guy...20:39
efriedwe're talking about whether, by installing a cyborg driver, you should automatically expose any device that driver can handle.20:39
efried...expose for attachability to VMs.20:39
efried...and if you want to reserve/restrict one, you have to explicitly blacklist it.20:40
edmondswyeah, that's probably not a great idea20:40
*** munimeha1 has quit IRC20:40
Sundarefried, edmondsw: If some of those devices come pre-installed in the physical servers, like built-in NICs, I can understand the need to blacklist by default. That is not the case for accelerators in the data center.20:41
efriedI mean, I'm having a tough time coming up with a practical scenario where it could cause you a real problem, it just feels wrong.20:41
edmondswdo we think there will never be a case where it makes sense for an accelerator to be owned by the hypervisor itself?20:42
Sundaredmondsw: Yes. That could be an explicit Cyborg configuration too.20:43
SundarIsn't one of the pain points of PCI whitelisting that there is so much operator labor required? That may be unavoidable for common elements like NICs, but hopefully can be avoided in most cases for accelerators.20:45
edmondswbut accelerators are going to become more and more common20:45
edmondswcould we compromise with a conf setting that allows the user to specify whether they want whitelist-by-default behavior or not?20:46
Sundaredmondsw: That seems reasonable. That is a single setting for an entire deployment.20:47
SundarWe still need that to coexist with Nova's PCI whitelists. The accelerator's PCI ID may be in te white list, due to operator error, or because an upgrade moved the device from Nova to Cyborg, or whatever20:49
SundarWe can help that by providing a tool that the operator runs, wherein he feeds the Nova's PCI whitelist file and  the output says which PCI IDs are in conflict20:49
Sundaredmondsw, efried: What do you think?20:50
efriedSundar: That sounds like an ambitious idea, but I'm sure it would be welcomed if you could pull it off :)20:51
efriedTBC, coexisting with the nova PCI whitelist in the sense that the set of devices managed by each are mutually exclusive.20:52
edmondswI'm not sure every conflict would be an error... but they could flick that conf setting to *not* whitelist-by-default in cyborg if that's the case20:52
edmondswI put that badly... I meant it wouldn't necessarily be a nova error... could be that they need to blacklist it in cyborg20:53
Sundaredmondsw: Sure.20:54
Sundarefried: Do you see practical issues with such a tool? It seems to me that the tool is merely scanning CYborg's db for PCI IDs and the operator-provided PCI whitelist file for conflicts. I suppose wild cards need careful handling20:55
efriedheh, yeah, good luck duplicating the logic nova uses to process that whitelist.20:55
Sundarefried: I'm probably being naive. How does Nova handle conflicts within the whitelist? Say one entry enables a device and another blacklists it.20:57
efriedSundar: Don't know off the top of my head.20:57
Sundarefried: NP. I nly intend this to be a helper tool, not some official way that is fool-proof20:58
efriedHere are the notes I scribbled down a couple years ago when I was pawing through the code trying to understand how it's "working":
efriedgosh, maybe it was only a year ago20:59
Sundarefried: Thanks for the notes.21:02
Sundarefried, edmondsw: Thanks for the good feedback. :)21:02
*** Sundar has quit IRC23:05
*** openstackgerrit has quit IRC23:49

Generated by 2.15.3 by Marius Gedminas - find it at!