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" <sr...@redhat.com
<mailto:sr...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev