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
