[openstack-dev] [nova] New image backend: StorPool

melanie witt melwittt at gmail.com
Mon Mar 19 20:45:54 UTC 2018

On Fri, 16 Mar 2018 19:24:01 +0200, Peter Penchev wrote:
> On Fri, Mar 16, 2018 at 09:23:11AM -0700, melanie witt wrote:
>> On Fri, 16 Mar 2018 17:33:30 +0200, Peter Penchev wrote:
>>> Would there be any major opposition to adding a StorPool shared
>>> storage image backend, so that our customers are not limited to
>>> volume-backed instances?  Right now, creating a StorPool volume and
>>> snapshot from a Glance image and then booting instances from that
>>> snapshot works great, but in some cases, including some provisioning
>>> and accounting systems on top of OpenStack, it would be preferable to
>>> go the Nova way and let the hypervisor think that it has a local(ish)
>>> image to work with, even though it's on shared storage anyway.
>> Can you be more specific about what is limiting you when you use
>> volume-backed instances?
> It's not a problem for our current customers, but we had an OpenStack
> PoC last year for a customer who was using some proprietary
> provisioning+accounting system on top of OpenStack (sorry, I really
> can't remember the name).  That particular system simply couldn't be
> bothered to create a volume-backed instance, so we "helped" by doing
> an insane hack: writing an almost-pass-through Compute API that would
> intercept the boot request and DTRT behind the scenes (send a modified
> request to the real Compute API), and then also writing
> an almost-pass-through Identity API that would intercept the requests to
> get the Compute API's endpoint and slip our API's address there.
> The customer ended up not using OpenStack for completely unrelated
> reasons, but there was certainly at least one instance of this.
>> We've been kicking around the idea of beefing up
>> support of boot-from-volume in nova such that "automatic boot-from-volume
>> for instance create" works well enough that we could consider
>> boot-from-volume the first-class way to support the vast variety of cinder
>> storage backends and let cinder handle the details instead of trying to
>> re-implement support of various storage backends in nova on a selective
>> basis. I'd like to better understand what is lacking for you when you use
>> boot-from-volume to leverage StorPool and determine whether it's something
>> we could address in nova.
> I'll see if I can remember anything more (ISTR also another case of
> something that couldn't boot a volume-backed instance, but I really
> cannot remember even what it was).  The problem was certainly not with
> OpenStack proper, but with other systems built on top of it.

Thanks for the insight, Peter. On both points, it looks like we could 
speculate that providing a good UX in nova for automatic 
boot-from-volume might have addressed the issues in other systems being 
unable to leverage it (boot-from-volume).

As it stands, we haven't had anyone interested enough in the idea of a 
generic cinder imagebackend in nova to come forward and work on it. As 
an alternative, we could enhance our support of boot-from-volume enough 
to make it easy/automatic to use if an environment needs to be able to 
take advantage of various cinder backends for instances.

If we can gather support and people willing to work on either of those 
options, we could start getting serious about a plan and make some 
progress toward it.


More information about the OpenStack-dev mailing list