<div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Matt Riedemann</b> <span dir="ltr"><<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>></span><br>Date: Thu, May 18, 2017 at 4:24 PM<br>Subject: [openstack-dev] [nova] Boston Forum session recap - cinder ephemeral storage<br>To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><br><br>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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
1. Short-term: provide a way to force automatic boot from volume in the API.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/BOS-forum-using-cinder-for-nova-ephemeral-storage" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/BOS-forum-using-cinder-for-<wbr>nova-ephemeral-storage</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:small">-- </span><br style="font-size:small"><div style="font-size:small"><div dir="ltr"><div dir="ltr">Kind regards,<br><br>Melvin Hillsman</div><div dir="ltr"><a href="mailto:mrhillsman@gmail.com" style="color:rgb(17,85,204)" target="_blank">mrhillsman@gmail.com</a><br>mobile: (832) 264-2646<br><br>Learner | Ideation | Belief | Responsibility | Command</div></div></div></div></div></div></div></div></div>
</div>