[openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953

Chris Friesen chris.friesen at windriver.com
Tue Nov 5 14:23:39 UTC 2013

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?)


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

More information about the OpenStack-dev mailing list