Open Stack

On Tue, Nov 12, 2013 at 8:46 AM, Solly Ross <sross at redhat.com> wrote:
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think the best solution here is to clean up the setting of
error-status for volumes during create/download and skip the timeout
altogether.  Last time I looked even this wasn't in that bad of shape
(with the exception of the phantom VG doesn't exist that none of us
seem to be able to recreate).  I'm not a fan of complex variable
time-out algorithms, and I'm even less of a fan of adding API
functions to gather timeout info.

I would like to hear if there's actually a solution offered by
call-backs that the rest of us just aren't seeing here?  I don't know
how that solves the problem though.