Open Stack

---------- Forwarded message ----------
From: Matt Riedemann <mriedemos at gmail.com>
Date: Thu, May 18, 2017 at 4:24 PM
Subject: [openstack-dev] [nova] Boston Forum session recap - cinder
ephemeral storage
To: openstack-dev at lists.openstack.org


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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170518/218f9f9b/attachment.html>