Open Stack

On Tue, Nov 12, 2013 at 2:02 PM, Caitlin Bestler
<caitlin.bestler at nexenta.com> wrote:
> On 11/12/2013 10:42 AM, John Griffith wrote:
>
>>
>> Sorry, but I'm not seeing where you're going with this in relation to
>> the question being asked?  The question is how to deal with creating a
>> new bootable volume from nova boot command and be able to tell whether
>> it's timed out, or errored while waiting for creation.  Not sure I'm
>> following your solution here, in an ideal scenario yes, if the backend
>> has a volume with the image already available they could utilize
>> things like cloning or snapshot features but that's a pretty
>> significant pre-req and I'm not sure how it relates to the general
>> problem that's being discussed.
>>
>
> I see the issue being discussed as "how to effectively deploy from Glance to
> Cinder boot images". Viewing the issue as being the lack
> of time-out or error messages on a path that was already too long
> is limiting.
>
> Yes, if you are going to deploy from Glance in that fashion then
> time-out and error messages are undoubtedly needed. The more important
> issue is that the this is instrumenting a poor method of deploying
> from Glance.
>
> There are indeed many steps in the more complete solution:
> * Check-out from glance for target environment.
> * Create snapshot
> * Replicate snapshot to desired target(s).
> * When bootable image is needed:
> *       Clone volume from snapshot.
> *       Boot from volume
>
> But all of those steps can be orchestrated behind a taskflow, which
> can also deal with Volume Drivers that do not efficiently snapshot.
>
> My point is that taking the shackles off of snapshots and making them
> first class Cinder objects is a solution to *many* problems - booting
> based upon a Glance master is just one of them.

Ok, not related to the OP's question.  We can start a specific Cinder
thread if you like but honestly many of us have "solved" this in a
sense already.  For those backends that support things like fast
cloning, COW's etc the solution in practice by users is to do the
create from image once, then clone that volume as a template.

This isn't exactly what you're getting at, however it's effective and
the implementation is universal (ie it works no matter what backend
you're using; granted some faster than others) but the implementation
details you describe are abstracted away so the end users or even the
operators don't have to care.

I understand your device has a high value on what it can do in terms
of snapshots, so by all means implement things like clone operations
to use that capability since you can have that object live
independently of the parent volume.  The point though is to keep as
much of that "specialized" behavior as possible hidden or abstracted
while providing equivalent semantics regardless of backend device
choices.

Feel free to start a separate Cinder thread if you'd like a broader discussion.

>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev