On Tue, Nov 12, 2013 at 10:25 AM, Caitlin Bestler <caitlin.best...@nexenta.com> wrote: > On 11/12/2013 8:09 AM, John Griffith wrote: >> >> 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. >>> > > Complexity is not an issue. Bandwidth and latency are issues. > > Any solution that achieves the user objectives can be managed by a taskflow. > It will be simple for the user to apply. The amount of code > involved is relatively low on the factors to compare. Taking extra time > and consuming extra bandwidth that were not required are serious issues. > > My assumption is that the cinder backend will be able to employ > copy-on-write when cloning volumes to at least make a thinly provisioned > version available almost instantly (even if the full space is allocated and > then copied asynchronously. Permanently thin clones just require that the > relationship be tracked. Currently that is up to the volume driver, but we > could always make these relationships legitimate by recognizing them in > Cinder proper).
Sorry, but I'm not seeing where you're going with this in relation to the question being asked? The question is how to deal with creating a new bootable volume from nova boot command and be able to tell whether it's timed out, or errored while waiting for creation. Not sure I'm following your solution here, in an ideal scenario yes, if the backend has a volume with the image already available they could utilize things like cloning or snapshot features but that's a pretty significant pre-req and I'm not sure how it relates to the general problem that's being discussed. > > The goal here is not to require new behaviors of backends, but to enable > solutions that already exist to be deployed to the benefit of end users. > Requiring synchronoous multi-GB copies (locally or even worse over the > network) is not a minor price that we should expect customers to endure > for the sake of software uniformity. > > > > > _______________________________________________ > 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