| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-26 | |||
| 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 | |
| 16:37:00 | mriedem | johnthetubaguy: what is the middle layer about the nova api? the enamel idea? | |
| 16:37:09 | mriedem | *above | |
| 16:37:17 | johnthetubaguy | mriedem: I think we thought heat might be that, but that turned out differently | |
| 16:37:45 | mriedem | nova today, as-is, provides the APIs you need for something sitting on top to do this stuff | |
| 16:37:58 | mriedem | which is why we've always pushed back on adding volume type to the compute api | |
| 16:38:08 | cburgess | mriedem johnthetubaguy I think we need to separate the flavor-root-disk-none and cinder backend idea entirely. The flavor-root-disk-none is a feature that regadless of backend disables a nova managed disk and requires BFV. It should be configured/enabled entirely independent of the cinder backend. | |
| 16:38:39 | cburgess | I think we should just return the 400, as painful as that is and don't do any other magic under the hood. | |
| 16:38:59 | johnthetubaguy | its basically saying, for this flavor, that optional argument is required | |
| 16:39:11 | johnthetubaguy | i mean thats messy, but all the other fixes seem miles out | |
| 16:39:25 | mriedem | cburgess: specifically so you can tie those types of flavors to certain host aggregates? | |
| 16:39:30 | cburgess | What do you mean by this optional argument is required? | |
| 16:39:40 | mriedem | bdms are optional when creating a server | |
| 16:39:47 | cburgess | Oh right yes. | |
| 16:39:50 | mriedem | a flavor saying they are required makes them non-optional | |
| 16:40:48 | cburgess | What if instead of local_disk=True/False we call it bdm_only=True/False. If false use existing logic if True, require BMD and ignore root/ephemeral/etc on flavor. | |
| 16:40:57 | cburgess | That seems like it might be a bit cleaner and less confusing? | |
| 16:41:04 | cburgess | or is it just symantics? | |
| 16:41:25 | johnthetubaguy | but the bdm can have source=local | |
| 16:41:32 | johnthetubaguy | I think | |
| 16:41:46 | cburgess | What? | |
| 16:41:47 | cburgess | Really? | |
| 16:41:50 | mriedem | yes | |
| 16:41:58 | mriedem | https://docs.openstack.org/developer/nova/block_device_mapping.html | |
| 16:41:58 | cburgess | That makes it use the hypervisor local instance path? | |
| 16:42:08 | johnthetubaguy | its maybe more volume_backed_disks_only=True | |
| 16:42:20 | johnthetubaguy | cburgess: yup | |
| 16:42:20 | cburgess | Dear lord... we made a mess. | |
| 16:42:23 | mgagne | what's the use case? Have a flavor with source=volume only? no local whatsoever? | |