<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 10:34 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 08/27/2013 10:06 AM, Alessandro Pilotti wrote:<br>

> We are also planning to implement the live snapshot feature in the<br>
> Hyper-V driver during the next release cycle.<br>
><br>
> I'm personally in favour of publishing the APIs in Havana, as this would<br>
> provide a stable baseline at the beginning of the release cycle and also<br>
<br>
</div>The API is published already.  What matters even more than the API for<br>
you as a driver maintainer is the driver interface, which is actually<br>
already merged.  It went in before it became clear the libvirt patch<br>
wouldn't go in, but I don't think there's any reason to remove it now.<br>
<div class="im"><br></div></blockquote><div> </div><div>Since the API is published already, where is the harm in offering a backing </div><div>implementation of it? This completes the picture and leaves only the virt</div>
<div>driver maintainers to finish up the work and they can do that in their own time</div><div>based on their own priorities and release schedule. </div><div><br></div><div>Ultimately the API implementation and the virt driver work is being done by</div>
<div>two distinct groups. I don't think its beneficial to block one group's efforts</div><div>because another group has different priorities. Especially since both groups</div><div>have expressed a desire to see the work in.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> give the ability to users and third parties to backport the driver's<br>
> feature to Havana (outside of the official repo of course).<br>
<br>
</div>If you're backporting stuff anyway, you can backport the API patch, as<br>
well.  I see no sense in delivering an API to *everyone* that can't be used.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div>Why require the additional hassle of backporting the API patch (which affects a</div><div>different sets of nodes / services than backporting pure driver support)? Especially</div>
<div>since the API patch simply fills in the implementation of the published API.</div><div><br></div><div>I understand that in the current outlook, Icehouse will be the release where this feature</div><div>really shines because it'll be supported by most of the virt drivers. However in the 6</div>
<div>months of the Havana release there is a rough patch of the functionality available in</div><div>Vish's libvirt patch. Yes, it is not the long term solution, unsupported by libvirt maintainers</div><div>and comes with a bunch of caveats around its use. But early adopters can certainly use</div>
<div>this patch to experiment with this API and see what interesting workflows come out of it.</div><div>That way they will be ready for when Icehouse lands with full support and it is ready for</div><div>primetime.</div>
<div><br></div><div>Thanks,</div><div>David Scannell </div><div> </div></div><br></div></div>