Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-03
19:11:21 exarr mriedem: I could bloody kiss you.
19:11:29 dansmith ew, a bloody kiss?
19:11:31 dansmith sounds terrible.
19:11:40 mriedem only on goth thursdays please
19:11:47 exarr :-)
19:23:27 openstackgerrit Chris Dent proposed openstack/nova-specs master: Add spec for symmetric GET and PUT of allocations https://review.openstack.org/508164
19:28:19 penick And now I have an image of mriedem dressed up as The Crow.
19:29:02 cdent penick: my eyes!
19:29:09 penick You're welcome.
19:32:27 openstackgerrit Chris Dent proposed openstack/nova-specs master: Add spec for symmetric GET and PUT of allocations https://review.openstack.org/508164
19:33:30 melwitt I wish I knew why we didn't already have disk quota in nova
19:34:14 penick I thought it used to be there, but left when cinder split out
19:34:27 openstackgerrit Chris Dent proposed openstack/nova master: [placement] gabbi tests for shared custom resource class https://review.openstack.org/485209
19:35:00 melwitt let me check the archived scrolls
19:35:34 penick I think it was in folsom, but got 'et by the Grizzly
19:35:34 cdent I’m now picturing melwitt (in the boots) sitting in dark loft with mriedem as crow “I wish I knew why…”
19:36:13 cdent mriedem gets up slowly from his crushed velvet chair
19:36:30 cdent fist clenched he walks to the broken window
19:36:34 cdent and shouts into the city
19:36:37 melwitt lol
19:37:06 penick I just assumed that was how his home office was configured
19:37:09 cdent WE STIILL DON’T KNOW
19:37:24 sdague I really don't think it was ever implemented
19:37:25 penick mriedem is an enigma wrapped in a tortilla
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 sdague using local disk that's just there doing nothing on computers was never the limiting factor for rax
19:38:52 melwitt yeah, so far not finding anything in the folsom-eol tag
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 mriedem heh https://review.openstack.org/#/c/218639/ still around
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: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 mriedem in the security impact section
20:13:32 cfriesen penick: mriedem: logically though any keys should belong to the project, not the individual user

Earlier   Later