Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-26
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 cburgess That makes it use the hypervisor local instance path?
16:41:58 mriedem https://docs.openstack.org/developer/nova/block_device_mapping.html
16:42:08 johnthetubaguy its maybe more volume_backed_disks_only=True
16:42:20 cburgess Dear lord... we made a mess.
16:42:20 johnthetubaguy cburgess: yup
16:42:23 mgagne what's the use case? Have a flavor with source=volume only? no local whatsoever?
16:42:28 johnthetubaguy cburgess: +1
16:42:30 cburgess mgagne Correct
16:42:46 cburgess mgagne Make it impossible to ever have nova create disks of any type local to the hypervisors.
16:43:04 mgagne like johnthetubaguy suggested, maybe we need to define the use cases that need to be supported because I see a lot of them
16:43:30 johnthetubaguy so some of them have API workarounds, some don't
16:43:44 johnthetubaguy I think the no_local_disk thing is the big one with no workarounds today
16:43:46 cburgess johnthetubaguy mriedem The other way to do this is make it a confug option on the compute side. Not a flavor extra spec.
16:43:52 mriedem nope
16:43:56 mgagne you can already restrict with max_local_block_devices but I think it's system-wide, not per aggregate or flavor
16:43:59 johnthetubaguy don't like configs changing the API behaviour
16:44:11 johnthetubaguy cburgess: so you get it wrong, and you just get an instance in the error state, I guess?
16:44:23 cburgess johnthetubaguy scheduler does it
16:44:31 cburgess The compute node reports it can't host local disk
16:44:46 johnthetubaguy you still get an instance in the error sate
16:44:49 johnthetubaguy I think
16:44:59 mgagne this means the request still manage to get to the scheduler, past the API
16:45:00 mriedem not if the scheduler can find a host that supports local disk
16:45:08 cburgess johnthetubaguy Thats not different then the 1000s of other things that the scheduler can barf on.
16:45:22 johnthetubaguy mgagne: I totally didn't know that existed, you are right, its API level I think
16:45:28 mriedem which eventually becomes a trait on the compute resource provider
16:45:39 cburgess mriedem Right which would be fine. If I want to support some local and some not that really a characteristic of the compute node directly.
16:45:44 johnthetubaguy mgagne: oh, I see your point, its system wide not per flaovr
16:45:56 cburgess mriedem Right.. I was thinking a trait.
16:46:03 mgagne yea so we would need something flavor scoped
16:46:04 cburgess This compute node can support local, this can't.
16:46:08 cburgess But thats a long way out again.
16:46:22 johnthetubaguy cburgess: yeah, I mean that all makes sense
16:46:26 mriedem johnthetubaguy: i knew about max_local_block_devices because people thought if you set it to 0 it meant nova would automagically always do bfv for you
16:46:35 johnthetubaguy mriedem: ah... right
16:46:44 johnthetubaguy mriedem: I remember that coming up now you mention it
16:46:46 cburgess I actually don't know what that setting does.
16:46:54 mgagne https://wiki.openstack.org/wiki/BlockDeviceConfig#max_local_block_devices
16:46:59 mriedem cburgess: traits are closer than everything else at this point
16:47:00 mgagne it's only to prevent DoS
16:47:04 johnthetubaguy gives you 400 errors, I presume
16:47:22 mgagne so people don't create an infinite amount of local disks
16:47:32 cburgess Ahh...
16:47:34 cburgess OK..

Earlier   Later