On Tue, Nov 5, 2013 at 6:29 AM, Chris Friesen <chris.frie...@windriver.com> wrote: > 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 > > > _______________________________________________ > 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
