Open Stack

On Tue, Nov 12, 2013 at 10:25 AM, Caitlin Bestler
<caitlin.bestler at nexenta.com> wrote:
> 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).

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev