| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-09-26 | |||
| 14:28:10 | xinran | About parse the flavor.extra_spec to the acceptable format to cyborg api | |
| 14:28:26 | xinran | Li_Liu: lol | |
| 14:28:53 | xinran | But these patches still need ovo land first | |
| 14:29:31 | Li_Liu | right, you might need to sync up with Coco and Xiaohei for that | |
| 14:30:03 | Li_Liu | Coco_gao wangzhh | |
| 14:30:07 | xinran | Li_Liu: yes, I have pull their patch to local and tested | |
| 14:30:30 | Coco_gao | the 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:32 | wangzhh | :) Xiaohei... | |
| 14:30:38 | wangzhh | Got it. | |
| 14:31:32 | Coco_gao | and evolve to the new version? | |
| 14:32:21 | wangzhh | Agree. I suggest keep the old one now. | |
| 14:33:41 | Coco_gao | everything will be changed after db evolution, the ovo, my patch on device object should also be rewritten. | |
| 14:34:06 | Li_Liu | I agree, let's keep the old one and decide when to remove it later | |
| 14:35:07 | xinran | The old one is the current one? | |
| 14:35:16 | Coco_gao | yes | |
| 14:35:16 | wangzhh | Coco, not really. Most of them can be reused. And we should hava a quick start. | |
| 14:35:23 | xinran | I mean acc dep these 2 tables | |
| 14:35:33 | Coco_gao | yes. | |
| 14:38:33 | xinran | Ok, but my placement repot patch depends on ovo now | |
| 14:42:41 | Li_Liu | ok, I think we are clear on the work item and their dependencies | |
| 14:42:58 | Li_Liu | Let's do this :) | |
| 14:43:04 | Li_Liu | #topic AoB | |
| 14:44:32 | Coco_gao | If we don't merge the two tables, then DB evolution is not urgent. Maybe I can do something more urgent right now. | |
| 14:46:52 | Li_Liu | Coco_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 again | |
| 14:47:18 | Coco_gao | I think so, not only xinran's code. | |
| 14:47:49 | Coco_gao | we finish rocky's target first? | |
| 14:48:00 | xinran | My code is now based on coco’s ovo patch :) | |
| 14:48:38 | Li_Liu | i see | |
| 14:49:02 | Coco_gao | Any feedback pls contact me directly, thanks xinran | |
| 14:49:10 | Li_Liu | Coco_gao, yes, try to finish up R's left over first | |
| 14:49:40 | xinran | So I think it’s ok for me if we use ovo design | |
| 14:51:26 | Coco_gao | I think the urgent thing is the docs~~ | |
| 14:51:26 | Li_Liu | alright, let's wrap up. | |
| 14:51:49 | Li_Liu | Coco_gao I will work with Sundar on that to speed it up | |
| 14:52:27 | Coco_gao | I can join from this week, feel free to contact me if I can help. | |
| 14:52:37 | Li_Liu | sure | |
| 14:52:41 | Li_Liu | thanks Coco | |
| 14:52:55 | Li_Liu | have a night night guys | |
| 14:52:59 | Li_Liu | #endmeeting | |
| 14:53:01 | wangzhh | Installation guide is urgent. | |
| 14:53:02 | openstack | Meeting ended Wed Sep 26 14:52:59 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 14:53:03 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-09-26-14.05.html | |
| 14:53:04 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-09-26-14.05.txt | |
| 14:53:05 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-09-26-14.05.log.html | |
| 14:53:06 | wangzhh | Bye | |
| 14:53:11 | Li_Liu | 88 | |
| 14:53:24 | xinran | bye | |
| 14:53:26 | Coco_gao | Bye | |
| 19:33:32 | Sundar | efried: Please ping me when you can | |
| 19:38:01 | efried | Sundar: Hi there. | |
| 19:42:33 | Sundar | Hi 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:45:02 | Sundar | Line 108 in https://review.openstack.org/#/c/603955 | |
| 20:26:41 | 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:27:31 | efried | sorry I missed your response earlier. ffr best to tag me | |
| 20:27:52 | efried | Not claiming, but exposing | |
| 20:28:34 | efried | If 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:48 | efried | Sundar: ^^ :) | |
| 20:29:32 | Sundar | Ah, yes, will make sure to tag you :) | |
| 20:30:18 | Sundar | efried: My statement was "if the operator has installed and configured Cyborg drivers, he has explicitly enabled the devices managed by those drivers." | |
| 20:30:38 | Sundar | Why is that a security risk? | |
| 20:31:02 | efried | Sundar: that should be fine. | |
| 20:31:40 | efried | sorry | |
| 20:31:43 | efried | strike that. | |
| 20:31:56 | Sundar | efried: NP. Will respond in the spec. Thanks. | |
| 20:32:12 | efried | Sundar: as worded, it implies that by installing cyborg, you've enabled the devices | |
| 20:32:47 | efried | Sundar: Is the "and configured" part where I would list which devices I wanted cyborg to manage? | |
| 20:33:30 | Sundar | Well, "installed Cyborg drivers". Installing a driver is a dleiberate act, right? | |
| 20:33:41 | Sundar | *deliberate | |
| 20:33:59 | efried | Yes. 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:34:35 | Sundar | I don't follow why that is a security risk. You may want to disable some, but that could be an explicit blacklist | |
| 20:35:11 | Sundar | If the admin doesn't want all those devices, why would he install them? | |
| 20:36:03 | efried | I'm no expert, but that's not how security works. | |
| 20:37:18 | Sundar | If some of those devices come pre-installed in the physical servers, like built-in NICs, I can understand. | |
| 20:37:56 | Sundar | I don;t think GPUs are pre-installed in data center class servers. (Desktops are a different story) | |
| 20:39:15 | efried | Sundar: 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:20 | efried | edmondsw: you're a security guy... | |
| 20:39:44 | efried | we're talking about whether, by installing a cyborg driver, you should automatically expose any device that driver can handle. | |
| 20:39:54 | efried | ...expose for attachability to VMs. | |
| 20:40:09 | efried | ...and if you want to reserve/restrict one, you have to explicitly blacklist it. | |
| 20:40:42 | edmondsw | yeah, that's probably not a great idea | |
| 20:41:03 | Sundar | efried, 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:57 | efried | I 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:42:43 | edmondsw | do we think there will never be a case where it makes sense for an accelerator to be owned by the hypervisor itself? | |
| 20:43:24 | Sundar | edmondsw: Yes. That could be an explicit Cyborg configuration too. | |
| 20:45:18 | Sundar | Isn'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:59 | edmondsw | but accelerators are going to become more and more common | |
| 20:46:54 | edmondsw | could we compromise with a conf setting that allows the user to specify whether they want whitelist-by-default behavior or not? | |
| 20:47:59 | Sundar | edmondsw: That seems reasonable. That is a single setting for an entire deployment. | |
| 20:49:13 | Sundar | We 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 whatever | |
| 20:49:59 | Sundar | We 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 conflict | |
| 20:50:23 | Sundar | edmondsw, efried: What do you think? | |
| 20:51:45 | efried | Sundar: That sounds like an ambitious idea, but I'm sure it would be welcomed if you could pull it off :) | |
| 20:52:25 | efried | TBC, coexisting with the nova PCI whitelist in the sense that the set of devices managed by each are mutually exclusive. | |
| 20:52:30 | edmondsw | I'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 case | |
| 20:53:18 | edmondsw | I put that badly... I meant it wouldn't necessarily be a nova error... could be that they need to blacklist it in cyborg | |
| 20:54:07 | Sundar | edmondsw: Sure. | |
| 20:55:08 | Sundar | efried: 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 handling | |
| 20:55:36 | efried | heh, yeah, good luck duplicating the logic nova uses to process that whitelist. | |
| 20:57:29 | Sundar | efried: 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:54 | efried | Sundar: Don't know off the top of my head. | |