Open Stack

On 08/27/2013 11:31 AM, David Scannell wrote:
> 
> 
> 
> On Tue, Aug 27, 2013 at 10:34 AM, Russell Bryant <rbryant at redhat.com
> <mailto:rbryant at redhat.com>> wrote:
> 
>     On 08/27/2013 10:06 AM, Alessandro Pilotti wrote:
>     > We are also planning to implement the live snapshot feature in the
>     > Hyper-V driver during the next release cycle.
>     >
>     > I'm personally in favour of publishing the APIs in Havana, as this
>     would
>     > provide a stable baseline at the beginning of the release cycle
>     and also
> 
>     The API is published already.  What matters even more than the API for
>     you as a driver maintainer is the driver interface, which is actually
>     already merged.  It went in before it became clear the libvirt patch
>     wouldn't go in, but I don't think there's any reason to remove it now.
> 
>  
> Since the API is published already, where is the harm in offering a backing 
> implementation of it? This completes the picture and leaves only the virt
> driver maintainers to finish up the work and they can do that in their
> own time
> based on their own priorities and release schedule. 

What backing implementation are you referring to?  And what schedule
exactly?

> Ultimately the API implementation and the virt driver work is being done by
> two distinct groups. I don't think its beneficial to block one group's
> efforts
> because another group has different priorities. Especially since both groups
> have expressed a desire to see the work in.

Nothing is blocked here.  The code needed to write virt driver support
is already merged.

> 
>     > give the ability to users and third parties to backport the driver's
>     > feature to Havana (outside of the official repo of course).
> 
>     If you're backporting stuff anyway, you can backport the API patch, as
>     well.  I see no sense in delivering an API to *everyone* that can't
>     be used.
> 
> Why require the additional hassle of backporting the API patch (which
> affects a
> different sets of nodes / services than backporting pure driver
> support)? Especially
> since the API patch simply fills in the implementation of the published API.

I've already made my stance pretty clear on this.  It doesn't make any
sense to me to merge an API that does not come with code to make it
usable.  It seems completely reasonable to wait to Icehouse when the
supporting code can come with it.

> I understand that in the current outlook, Icehouse will be the release
> where this feature
> really shines because it'll be supported by most of the virt drivers.
> However in the 6
> months of the Havana release there is a rough patch of the functionality
> available in
> Vish's libvirt patch. Yes, it is not the long term solution, unsupported
> by libvirt maintainers
> and comes with a bunch of caveats around its use. But early adopters can
> certainly use
> this patch to experiment with this API and see what interesting
> workflows come out of it.
> That way they will be ready for when Icehouse lands with full support
> and it is ready for
> primetime.

Regarding the libvirt patch, it comes down to, are we willing to merge
something that the supporting virt platform is not willing to support?

It's clear we don't have 100% agreement on this, but my stance on that
question is no.

I didn't make that decision lightly.  I tried to review the stance from
everyone speaking up.  We have Dan Berrange, a lead developer of
libvirt, as well as a nova-core member, as well as a couple of others
from the libvirt community, saying this unsupportable.  That's pretty
much a show stopper for me.

-- 
Russell Bryant