Open Stack

The etherpad for this session is here [1]. 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.

[1] 
https://etherpad.openstack.org/p/BOS-forum-using-cinder-for-nova-ephemeral-storage

-- 

Thanks,

Matt

-- 

Thanks,

Matt