Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-26
16:14:05 mriedem i agree you get a user visible cinder volume that you wouldn't have before,
16:14:17 edleafe ` /win 14
16:14:20 mriedem but i'm not sure that's a huge issue as long as it's marked for delete_on_termination=True
16:14:21 cburgess What do we mean by "wouldn't have before"?
16:14:34 mriedem wouldn't have before "automatically"
16:14:39 mriedem today you opt in to bfv
16:14:58 mriedem this would have nova do it for you depending on which compute host you land on
16:15:09 cburgess OK right but, presumably it would be a deployer, or at least cloud admin, option to use the new as of yet unspeced nova roots on cinder idea.
16:15:33 mriedem yes it would be
16:15:42 cburgess So I don't think its a problem that users would see the cinder volumes.
16:15:49 mriedem as would marking your flavors as local_disks=False like in https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/flavor-root-disk-none.html
16:15:56 cburgess In pure BFV environments today they already deal with that.
16:16:28 mriedem it's just with https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/flavor-root-disk-none.html if the user picks the wrong flavor or makes the wrong server create request, it will blow up
16:16:36 mriedem and then they have to go back and figure out how to add bdms via the nova boot cli
16:16:37 mriedem which is not fun
16:16:37 cburgess How so?
16:16:40 cburgess I'm not following.
16:16:54 mriedem "The use case for End Users is to not create ephemeral (root) disks locally on the hypervisor by accident. When launching an instance from a flavor with disabled local disks, the user will be informed to create a bootable volume in order to launch the instance with that volume."
16:17:05 mriedem "be informed" means 400
16:17:45 mriedem holy crap, just look at the proposed change minefield
16:17:47 mriedem "error, when flavor create request with local_disks=False and root_gb > 0 and/or emphemeral_gb > 0 and/or swap_gb > 0"
16:18:02 mriedem "return descriptive exception, when flavor with local_disks=False and requested image larger than given blockdevice layout"
16:18:07 mriedem "if local_disks is omitted or set to True, root_gb is mandatory again"
16:18:22 mriedem "if jupiter is aligned with saturn and it's a leap year, the api works, else 400"
16:18:37 cburgess Yeah this seems... sub-optimal.
16:18:44 cdent what about when mercury is in retrograde?
16:18:53 cburgess Why can't we use the rest of the info from the boot request and craft a BFV request for them.
16:18:59 mriedem cdent: then all bets are off
16:19:16 mriedem cburgess: that's probably https://review.openstack.org/#/c/432503/
16:19:18 cburgess Granted... turning off local disks is a really big deal/issue today and causes us issues.
16:20:02 johnthetubaguy right, its not possible today, due to root_gb=0 meaning "don't resize image"
16:20:07 cburgess mriedem Yeah but you killed that. So it seems to me that if we do local_disk=False we either need to build the BDM under the covers, or we need to allow the BDM in the flavor as well.
16:20:34 cburgess johnthetubaguy How does that impact this exactly?
16:20:40 mriedem if we build the bdm under the coveres if local_disk=False, that's the same thing as https://review.openstack.org/#/c/432503/
16:20:45 mriedem just a different attribute on the flavor
16:20:56 mriedem ^ was doing is_bdm_flavor=True on the flavor
16:20:58 mriedem same idea
16:21:01 cburgess OK
16:21:02 cburgess Well...
16:21:08 johnthetubaguy cburgess: people often assume 0 GB means no disk
16:21:20 cburgess Honestly it seems reasonable to me. But then I thought that spec was reasonable to begin with.
16:21:25 cburgess johnthetubaguy Well they are wrong :P
16:21:30 johnthetubaguy cburgess: agreed
16:21:35 mriedem cburgess: you're saying you like both ideas
16:21:45 mriedem the abandoned spec, and the extra specs / bfv thing
16:21:59 mriedem cburgess: you like anything that gets rid of your local patches :)
16:21:59 cburgess mriedem I'm saying disks are a total and complete mess and we have to find ways of making this easier and better to consume because right now the whole thing is a confusing mess.
16:22:33 cburgess mriedem Yes.. but... I have those local patches because things are a mess. So I like anything that makes a cleaner, easier to use system for users.
16:22:48 mriedem yeah i know,
16:23:00 mriedem if a cinder ephemeral imagebackend is never going to happen, then maybe we go with https://review.openstack.org/#/c/432503/
16:23:14 mriedem i just really dislike coupling two terrible tech debt things in nova, extra specs and bdms
16:23:21 mriedem because that's bound to be a maintenance nightmare
16:23:32 cburgess Well I think a cinder ephemeral imagebackend is a long term thing. Question is what, if anything, can we do in a cycle or two.
16:23:44 smcginnis I've been seeing more and more requests for using Cinder as ephemeral storage.
16:23:57 mriedem cburgess: nothing is happening in pike
16:24:05 mriedem b/c nothing was proposed before spec freeze
16:24:24 mriedem smcginnis: yes it has been for a long time, the question is how to best provide it w/o adding a bunch of tech debt to nova
16:24:50 cburgess agreed
16:24:57 mriedem as i said earlier, we already have apis that don't work with volume-backed instances
16:25:10 mriedem like, maybe we should fix some of that...
16:25:13 johnthetubaguy mriedem: but is that actually true? or just a bug?
16:25:17 cburgess mriedem I know Boston isn't supposed to be a summit but... I kind of feel like we need a working session at some point to lay out what the correct roadmap for storage is.
16:25:40 mriedem johnthetubaguy: bugs, but big hairy bugs
16:25:45 cburgess mriedem Because we have been dancing around these issues for 2 cycles nw.
16:25:45 cdent cburgess: hasn't that sesssion happened at every summit for the last several years?
16:25:57 mriedem johnthetubaguy: cfriesen was just asking about volume-backed instance rebuild yesterday and how it doesn't work
16:26:06 stackempty mriedem: so what would be my options for now .. to have something close to preventing local disk storage on the hypervisor ?
16:26:09 EmilienM mriedem: hi, I was afk this morning. Please let me know how can I help wrt wsgi
16:26:12 mgagne hehe, we used to have a similar need (default to BFV) in the past and implemented it with an ugly middleware: https://gist.github.com/mgagne/161bd7eaeb4c747fa1ae97c0bc43c093
16:26:14 cburgess cdent Sort of. We keep doing it in terms of a feature request or two from individual parties (multi-attach, volume-type, etc).
16:26:37 cburgess cdent I'm thinking we need a more high level, ignoring all individual feature requests, what do we have now and where do we need to involve it too
16:26:38 mriedem stackempty: it sounds like lots of providers have implemented downstream solutions
16:26:42 mriedem as cburgess and mgagne pointed out
16:26:50 johnthetubaguy mriedem: OK, I guess we have concrete examples then
16:27:19 mriedem johnthetubaguy: i had something in the ML recently about how shelve/unshelve is just totally ignorant wrt volues
16:27:21 mriedem *volumes
16:27:31 mriedem and we've had bugs open for over a year that haven't been resolved
16:27:37 cburgess mriedem Another case for removing that feature
16:27:39 johnthetubaguy mriedem: yeah, that whole feature is un finished, so I expected that of shelve
16:28:32 johnthetubaguy cburgess: thats not a crazy plan
16:28:36 mriedem mgagne: ok so that basically does https://review.openstack.org/#/c/432503/
16:28:40 mriedem just via paste middleware
16:29:13 johnthetubaguy so is this a middle ground?
16:29:20 johnthetubaguy we do https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/flavor-root-disk-none.html
16:29:21 cburgess johnthetubaguy Never understood that one.
16:29:34 cburgess johnthetubaguy The shelve/unshevle feature I mean
16:29:46 mgagne mriedem: yea, idea was to not be intrusive to nova code, a bit like wafflehaus from rax
16:30:00 johnthetubaguy cburgess: it was to do "stop" instance for local disks, where you only pay for the IP when it is shelved
16:30:21 cburgess johnthetubaguy Creates all types of state and capacity management issues.
16:30:28 cburgess johnthetubaguy Don't like it, never liked it, anywho.. back to storage.
16:30:39 johnthetubaguy cburgess: allowing users to keep ports somehow, would be better
16:30:48 johnthetubaguy yeah
16:30:55 johnthetubaguy ... so middle ground, possibly
16:31:04 johnthetubaguy we do the 400 error if no BDMs
16:31:07 cburgess Right..
16:31:11 johnthetubaguy once we have cinder backend in place
16:31:23 johnthetubaguy the 400 becomes an auto create of that thing
16:31:43 johnthetubaguy ... actually thats messed up in a heap of other ways :(
16:31:46 mriedem johnthetubaguy: ^ means the api needs to know the compute is configured and capable of using cinder
16:31:51 cburgess Honestly its ugly to do the 400 but it operationally better then today where you end up with instances sprinkled on hypervisor local storage and having to work iwht users to migrate the data to a volume and rebuild the instance with a volume.

Earlier   Later