<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 12:55 PM, Roman Bogorodskiy <span dir="ltr"><<a href="mailto:rbogorodskiy@mirantis.com" target="_blank">rbogorodskiy@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>  Eric Windisch wrote:<br>
<br>
> This thread highlights more deeply the problems for the FreeBSD folks.<br>
> First, I still disagree with the recommendation that they contribute to<br>
> libvirt. It's a classic example of creating two or more problems from one.<br>
> Once they have support in libvirt, how long before their code is in a<br>
> version of libvirt acceptable to Nova? When they hit edge-cases or bugs,<br>
> requiring changes in libvirt, how long before those fixes are accepted by<br>
> Nova?<br>
<br>
</div>Could you please elaborate why you disagree on the contributing patches<br>
to libvirt approach and what the alternative approach do you propose?<br></blockquote><div><br></div><div>I don't necessarily disagree with contributing patches to libvirt. I believe that the current system makes it difficult to perform quick, iterative development. I wish to see this thread attempt to solve that problem and reduce the barrier to getting stuff done.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Also, could you please elaborate on what is 'version of libvirt<br>
acceptable to Nova'? Cannot we just say that e.g. Nova requires libvirt<br>
X.Y to be deployed on FreeBSD?<br></blockquote><div><br></div><div>This is precisely my point, that we need to support different versions of libvirt and to test those versions. If we're going to support  different versions of libvirt on FreeBSD, Ubuntu, and RedHat - those should be tested, possibly as third-party options.</div>

<div><br></div><div>The primary testing path for libvirt upstream should be with the latest stable release with a non-voting test against trunk. There might be value in testing against a development snapshot as well, where we know there are features we want in an unreleased version of libvirt but where we cannot trust trunk to be stable enough for gate.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, speaking about FreeBSD support I assume we actually talking<br>
about Bhyve support. I think it'd be good to break the task and<br>
implement FreeBSD support for libvirt/Qemu first</blockquote><div><br></div><div> I believe Sean was referencing to Bhyve support, this is how I interpreted it.</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">

Regards,<div>Eric Windisch</div></div>
</div></div>