Open Stack

On 11/12/2013 8:09 AM, John Griffith wrote:
> On Tue, Nov 12, 2013 at 8:46 AM, Solly Ross <sross at 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" <sross at redhat.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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).

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.