| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-26 | |||
| 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 | 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:21:59 | mriedem | cburgess: you like anything that gets rid of your local patches :) | |
| 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 | cdent | cburgess: hasn't that sesssion happened at every summit for the last several years? | |
| 16:25:45 | cburgess | mriedem Because we have been dancing around these issues for 2 cycles nw. | |
| 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. | |
| 16:32:12 | johnthetubaguy | mriedem: well, its a resource request, I think | |
| 16:32:31 | johnthetubaguy | cburgess: thats where I am, but I am biased, its what public cloud carries as a patch right now | |
| 16:32:32 | cburgess | Why do we need to do anything once we have the cinder backend? | |
| 16:32:56 | johnthetubaguy | so with cinder backend, you want to pick between local disk and cinder back end flavors | |
| 16:33:07 | johnthetubaguy | so its more you get to re-use it | |
| 16:33:19 | johnthetubaguy | meh, thats way too messy | |
| 16:33:32 | cburgess | Well.. | |
| 16:33:42 | cburgess | So today you pick a storage backend by selecting an AZ/aggregate. | |
| 16:33:51 | cburgess | Since you can only have a single one today | |
| 16:34:01 | cburgess | I guess once we can support different storage backends on a single node. | |
| 16:34:08 | johnthetubaguy | I guess, via flavor extra specs I presume? | |
| 16:34:13 | cburgess | Correct | |
| 16:34:16 | cburgess | So here is the thing | |
| 16:34:35 | cburgess | Once we have the cinder backend we will have to be able to pass things like volume type, size ,etc. | |
| 16:34:41 | johnthetubaguy | yeah | |
| 16:34:48 | cburgess | Some of them exist as existing attributes on flavors (root_gb) but others don't and will be required. | |
| 16:35:01 | mriedem | type is the only one that's missing right? | |
| 16:35:12 | mgagne | you can have a default volume type in cinder | |
| 16:35:13 | cburgess | mriedem I would have to look at it and think about it. | |
| 16:35:21 | mgagne | unless you wish for your flavor to default to a different one | |
| 16:35:23 | cburgess | mgagne Thats not sufficient | |
| 16:35:27 | cburgess | mgagne Right exactly. | |
| 16:35:36 | cburgess | mgagne A single default of the entire cloud is... limiting. | |
| 16:35:47 | mgagne | sure, we both agree =) | |
| 16:36:07 | johnthetubaguy | I think the problem here is the middle layer about the Nova API hasn't ever come into existance | |
| 16:36:14 | johnthetubaguy | s/about/above/ | |
| 16:36:28 | mriedem | stackempty: remember 40 minutes ago when i said you stepped into something? :) | |
| 16:36:55 | smcginnis | cburgess: +1 | |
| 16:36:59 | johnthetubaguy | feels like we need the use cases writing up and agreeing to move forward | |