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.
Best,
-melanie
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
