| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 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? :) | |
| 20:21:02 | sdague | anyway, I tried to build a summary email from all the conversations I saw today | |
| 20:21:03 | cfriesen | dansmith: fair enough...so in mriedem's scenario would we allow user B to replace user A's "mykey" with user B's "mykey" on a rebuild? | |
| 20:21:30 | dansmith | IMHO, if you specify a key, it's looked up based on your context, and if that's your key instead of the original one, then so be it | |
| 20:21:50 | sdague | dansmith: sure, I just think it might be an unexpected thing | |
| 20:21:53 | dansmith | if you don't, then we should keep the same I think | |
| 20:22:14 | dansmith | sdague: if you specify a key? you can't list other people's keys so what other intent could the user have if they specify one? | |
| 20:22:30 | penick | Well for preserving the host key, the private key will need to be stored as well | |
| 20:22:38 | sdague | penick: we don't do that | |
| 20:22:41 | penick | there's no point in keeping a public ssh host key, if you don't preserve the private key | |
| 20:22:43 | dansmith | penick: we do nothing with the host key | |
| 20:22:55 | penick | Oh hell, I completely misunderstood this spec. | |
| 20:22:55 | dansmith | these are all user access keys we're talking about | |
| 20:22:58 | sdague | this is all just the root ssh key | |
| 20:23:02 | sdague | root user | |