Open Stack

I'd like to get some sort of consensus on this before I start working on it.  Now that people are back from Summit, what would you propose?

Best Regards,
Solly Ross

----- Original Message -----
From: "Solly Ross" <sross at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Sent: Tuesday, November 5, 2013 10:40:48 AM
Subject: Re: [openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953

Also, that's still an overly complicated process for one or two VMs.  The idea behind the Nova command was to minimize the steps in the image->volume->VM process for a single VM.

----- Original Message -----
From: "Chris Friesen" <chris.friesen at windriver.com>
To: openstack-dev at lists.openstack.org
Sent: Tuesday, November 5, 2013 9:23:39 AM
Subject: Re: [openstack-dev] Improvement of Cinder API wrt	https://bugs.launchpad.net/nova/+bug/1213953

Wouldn't you still need variable timeouts?  I'm assuming that copying 
multi-gig cinder volumes might take a while, even if it's local.  (Or 
are you assuming copy-on-write?)

Chris

On 11/05/2013 01:43 AM, Caitlin Bestler wrote:
> Replication of snapshots is one solution to this.
>
> You create a Cinder Volume once. snapshot it. Then replicate to the
> hosts that need it (this is the piece currently missing). Then you clone
> there.
>
> I will be giving an in an hour in conference session on this and other
> uses of snapshots in the last time slot Wednesday.
>
> On Nov 5, 2013 5:58 AM, "Solly Ross" <sross at redhat.com
> <mailto:sross at redhat.com>> wrote:
>
>     So,
>     There's currently an outstanding issue with regards to a Nova
>     shortcut command that creates a volume from an image and then boots
>     from it in one fell swoop.  The gist of the issue is that there is
>     currently a set timeout which can time out before the volume
>     creation has finished (it's designed to time out in case there is an
>     error), in cases where the image download or volume creation takes
>     an extended period of time (e.g. under a Gluster backend for Cinder
>     with certain network conditions).
>
>     The proposed solution is a modification to the Cinder API to provide
>     more detail on what exactly is going on, so that we could
>     programmatically tune the timeout.  My initial thought is to create
>     a new column in the Volume table called 'status_detail' to provide
>     more detailed information about the current status.  For instance,
>     for the 'downloading' status, we could have 'status_detail' be the
>     completion percentage or JSON containing the total size and the
>     current amount copied.  This way, at each interval we could check to
>     see if the amount copied had changed, and trigger the timeout if it
>     had not, instead of blindly assuming that the operation will
>     complete within a given amount of time.
>
>     What do people think?  Would there be a better way to do this?
>
>     Best Regards,
>     Solly Ross
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

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