On Tue, Nov 12, 2013 at 8:46 AM, Solly Ross <sr...@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" <sr...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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.frie...@windriver.com> > To: openstack-dev@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" <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 > > _______________________________________________ > 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
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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
