Open Stack

On 11/04/2013 03:49 PM, Solly Ross 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?

The only other option I can think of would be some kind of callback that 
cinder could explicitly call to drive updates and/or notifications of 
faults rather than needing to wait for a timeout.  Possibly a 
combination of both would be best, that way you could add a --poll 
option to the "create volume and boot" CLI command.

I come from the kernel-hacking world and most things there involve 
event-driven callbacks.  Looking at the openstack code I was kind of 
surprised to see hardcoded timeouts and RPC casts with no callbacks to 
indicate completion.

Chris