[openstack-dev] [nova] Boston Forum session recap - cinder ephemeral storage
mriedemos at gmail.com
Thu May 18 21:24:41 UTC 2017
The etherpad for this session is here . The goal for this session was
figuring out the use cases for using Cinder as instance ephemeral
storage and short/long-term solutions.
This really came down to a single use case, which is as an operator I
want to use Cinder for all of my storage needs, which means minimal
local compute disk is used for VMs.
We discussed several solutions to this problem which are detailed with
pros/cons in the etherpad. We arrived at two solutions, one is
short-term and one is long-term:
1. Short-term: provide a way to force automatic boot from volume in the API.
John Griffith had a POC for doing this with flavor extra specs which are
controlled by the admin and by default are not discoverable by the API
user. There are downsides to this, like the fact that the API user isn't
specifying BDMs but while their server is creating, they see a volume
pop up in Horizon which they didn't expect (which is for their root
disk) and since they don't want to be charged for it, they delete it -
which makes the server go into ERROR state eventually (and is not
retried). This just makes for a weird/bad user experience and it was
unclear how to microversion this in the API so it's discoverable, plus
it couples two complicated debt-ridden pieces of Nova code: flavor extra
specs and block device mappings. It is, however, fairly simple to implement.
2. Long-term: write an image backend driver which is a proxy to Cinder.
This would not require any changes to the API, it's all configurable
per-compute, it would remove the need for the in-tree RBD/ScaleIO/LVM
image backends, and open up support for all other Cinder volume drivers
- plus we'd allow passing through a volume type via flavor extra spec in
this case. This option, however, has no owner, and is dependent on
working it into an area of the code that is very complicated and high
technical debt right now (the libvirt imagebackend code). So while we
all agreed we'd love to have this, it's not even really on the horizon.
As a compromise on the short-term option, I suggested that we avoid
using flavor extra specs to embed auto-BFV and instead put a new
attribute directly on the flavor, e.g. is_volume_backed, or something
like that. This would be in a microversion which makes it discoverable.
Operators control the flavors so they can control which ones have this
flag set, and could tie those flavors to host aggregates for compute
hosts where they want to avoid local disk for ephemeral storage.
The next step from this session is going to be fleshing out this idea
into a spec which can be discussed for the Queens release, which would
also include details on the alternatives in the etherpad and the
pros/cons for each so we don't lose that information. Unless someone
beats me to it, I think I'm signed up for writing this spec.
More information about the OpenStack-dev