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

Reply via email to