| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 19:37:34 | sdague | I thought I ran this code stream a couple months ago | |
| 19:38:19 | sdague | because quota only matters for the things you have the least of | |
| 19:38:52 | melwitt | yeah, so far not finding anything in the folsom-eol tag | |
| 19:38:52 | sdague | using local disk that's just there doing nothing on computers was never the limiting factor for rax | |
| 19:38:54 | mriedem | disk quota also gets goofed up when you're talking about boot from volume | |
| 19:39:14 | sdague | mriedem: right, there is quota on volumes, because that's off the expensive storage units | |
| 19:39:25 | mriedem | is it that time of the week to link in that change again? | |
| 19:39:39 | cdent | the words dripped from mriedem’s black lips | |
| 19:39:40 | cdent | boot | |
| 19:39:41 | cdent | from | |
| 19:39:44 | cdent | volume | |
| 19:39:49 | mriedem | https://review.openstack.org/#/c/428481/ | |
| 19:40:02 | melwitt | so not only will ppl be complaining about consuming > 0 disk with BFV they'll also complain about consuming > 0 quota with BFV | |
| 19:40:28 | sdague | heh | |
| 19:40:37 | sdague | yeh, well landing that would clearly be a prereq | |
| 19:41:11 | sdague | I guess disk quota only really makes sense when your instances are all on network storage like ceph or nfs, right? | |
| 19:41:17 | melwitt | I have at least two patches that are like "the patches that shall not be named" | |
| 19:41:30 | sdague | which basically didn't work back then anyway | |
| 19:41:32 | melwitt | that one and then there's the thrice reverted bug fix one | |
| 19:43:20 | melwitt | sdague: hm, yeah ... the spec says they want to be able to bill for storage and restrict storage and currently the only way to do that is with cinder volumes | |
| 19:43:20 | mriedem | heh https://review.openstack.org/#/c/218639/ still around | |
| 19:43:31 | mriedem | when is the last time someone ran the auto-abandon script | |
| 19:44:01 | sdague | mriedem: it's been a while | |
| 19:45:34 | mriedem | several other bugs like this: create instance, attach volume, snapshot instance (the snapshot image has bdms in it now), create another instance, rebuild that 2nd instance with the snapshot image with image-defined-bdms, kablammo | |
| 19:45:52 | sdague | melwitt: right, I guess if you have flavors with a wide range of disk storage sizes, vs. coupling them to the mem/cpu sizing | |
| 19:47:05 | sdague | mriedem: so... I feel like there were enough interesting side conversations about the key_pair thing that they probably warrent a summary email, they will not capture very cleanly in 2 specs and 4 irc threads | |
| 19:47:10 | sdague | I can write that up if you like | |
| 19:47:34 | melwitt | yeah, must be. I haven't really heard this come up before, so it's probably like you said, for most ppl the limiting factor is cpu/mem | |
| 19:48:17 | mriedem | sdague: that's probably a good idea | |
| 19:53:09 | mriedem | is any of the accessIPv4 still valid? | |
| 19:53:16 | mriedem | *accessIPv4 stuff | |
| 19:53:30 | mriedem | that seems to be another one of those legacy things which we don't test but it's all over the api | |
| 19:53:38 | mriedem | like diskConfig | |
| 19:54:27 | sdague | it's user facing | |
| 19:54:32 | sdague | and user updatable | |
| 19:54:43 | sdague | sometimes it gets filled out, depending on the config | |
| 19:55:06 | sdague | if you update it yourself, we don't validate it, it's just reflected | |
| 19:55:23 | sdague | mriedem: ok, because it's been a while, a rebuild doesn't go through the scheduler, right? | |
| 19:55:47 | sdague | you get to rebuild in place, which means it's probably faster because your base image is already tehre | |
| 19:55:51 | sdague | correct? | |
| 19:56:02 | mriedem | sdague: rebuild (not evacuate) bypasses the scheduler yes | |
| 19:56:04 | sdague | I'm trying to make sure I cover all the reasons this could be interesting | |
| 20:00:28 | sdague | also, out of curiosity, because of the user scoping of keys, if you rebuild someone else's instance in the same project today, does it actually scope check the key and not add it? | |
| 20:02:16 | penick | that's an interesting question | |
| 20:03:46 | mriedem | sdague: you mean in the proposed spec? | |
| 20:03:48 | mriedem | or today? | |
| 20:04:01 | mriedem | because you can't change the key on rebuild today, hence the spec | |
| 20:04:53 | sdague | mriedem: no | |
| 20:05:00 | sdague | I mean, you build a server with your key | |
| 20:05:03 | sdague | I'm in your project | |
| 20:05:07 | sdague | I rebuild your server | |
| 20:05:09 | sdague | but I'm not you | |
| 20:05:18 | sdague | and I don't have access to your key | |
| 20:05:22 | sdague | what happens | |
| 20:06:23 | sdague | do we "never check that scope" | |
| 20:06:32 | sdague | do we "check the scope and not add the key" | |
| 20:06:54 | mriedem | just because you rebuild my server doesn't mean you get access to my key to ssh into it, right? | |
| 20:07:05 | mriedem | so i'm not seeing the issue | |
| 20:09:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: remove redundant preserve_ephemeral mention from rebuild docs https://review.openstack.org/509273 | |
| 20:10:11 | penick | mriedem but isn't there a spec to add userdata to rebuild? | |
| 20:10:21 | mriedem | no | |
| 20:10:33 | penick | Or maybe I took crazy pills | |
| 20:10:44 | mriedem | there is a spec to remove personality files from rebuild, | |
| 20:10:47 | melwitt | penick: they're talking about the nova keypair API. | |
| 20:11:05 | mriedem | we're really talking about like 5 things | |
| 20:11:16 | mriedem | there is a spec proposed to pass a new key_name during rebuild, | |
| 20:11:25 | mriedem | there is a spec proposed to remove peronality files from server create and rebuild | |
| 20:11:47 | cfriesen | jaypipes: thanks for the suggestions on https://review.openstack.org/#/c/46820 (proposing "hw:realtime_cpu_set"). I imagine we'd need to support both "set" and "mask" for a release or two? | |
| 20:11:52 | mriedem | the question came up if we should allow passing new user_data during rebuild if we're not going to allow passing personality files anymore, and the spec currently states that we will not allow that | |
| 20:12:03 | penick | Yeah, my concern was if I can rebuild your instance, and that rebuild pulls in your user ssh keys, and If I can do something to inject my user into your instance on rebuild then i'd gain access to your ssh keys. | |
| 20:12:29 | melwitt | penick: if two ppl are in the same project and one person A creates an instance with their --key_name in it and the second person B does a rebuild on person A's instance, what happens to the key | |
| 20:12:42 | cfriesen | penick: resources are owned by projects, not individual users | |
| 20:12:50 | mriedem | cfriesen: except keys | |
| 20:13:16 | mriedem | penick: i think your question belongs in https://review.openstack.org/#/c/375221/ | |
| 20:13:32 | cfriesen | penick: mriedem: logically though any keys should belong to the project, not the individual user | |
| 20:13:32 | mriedem | in the security impact section | |
| 20:14:04 | mriedem | i think what would happen here is if you specified a new key_name during rebuild, we are going to be looking up that keypair in the api to see if it exists, | |
| 20:14:11 | mriedem | that check is going to use the context.user_id, | |
| 20:14:32 | mriedem | and if you're rebuilding my server, and don't have access to my keys, that keypair lookup will fail and you'll get an error | |
| 20:14:54 | mriedem | now if user A and user B are in the same project, and both have a key named mykey, that could work, but the user A mykey and user B mykey should still be different | |
| 20:15:00 | penick | melwitt: yeah that's what i'm wondering | |
| 20:15:51 | cfriesen | mriedem: why did we ever tie keys to users? | |
| 20:16:39 | mriedem | you will have to ask someone else | |
| 20:16:48 | mriedem | but, why wouldn't we? | |
| 20:16:50 | mriedem | keys are private | |
| 20:16:55 | melwitt | probably bc when you create one via the API it gives you the private key | |
| 20:16:55 | penick | cfriesen: it makes sense for user ssh keys. Just not for headless keys or server keys | |
| 20:17:20 | mriedem | are we venturing into the application credentials hullabaloo? | |
| 20:17:20 | cfriesen | mriedem: instances are owned by the project. keys are used to access instances. therefore keys should be owned by the project | |
| 20:17:31 | sdague | it is only the public keys that we store | |
| 20:17:39 | sdague | so it's not really a security risk | |
| 20:17:47 | sdague | but it's funny that you can't list those keys for other users | |
| 20:18:01 | sdague | but they can be put on a server for you | |
| 20:18:04 | cfriesen | melwitt: sure, then you dump the private key into some local "project team storage area" with permission controls | |
| 20:18:44 | dansmith | does this matter at all? we'd have to do some pretty major surgery to change the ownership of keys, and it would be hard to support old microversions for them | |
| 20:18:48 | sdague | cfriesen: keys attached to users are from "the before time" | |
| 20:19:35 | dansmith | unless we're really going to change key ownership, we might as well talk about problems we're going to solve | |
| 20:20:21 | sdague | dansmith: yeh, it's just an interesting edge question about how the system works because of the scope mismatch | |
| 20:20:40 | dansmith | sure, | |
| 20:20:52 | dansmith | but then we can move on once identified right? :) | |