Open Stack

On Wed, Jul 16, 2014 at 12:55 PM, Roman Bogorodskiy <
rbogorodskiy at mirantis.com> wrote:

>   Eric Windisch wrote:
>
> > This thread highlights more deeply the problems for the FreeBSD folks.
> > First, I still disagree with the recommendation that they contribute to
> > libvirt. It's a classic example of creating two or more problems from
> one.
> > Once they have support in libvirt, how long before their code is in a
> > version of libvirt acceptable to Nova? When they hit edge-cases or bugs,
> > requiring changes in libvirt, how long before those fixes are accepted by
> > Nova?
>
> Could you please elaborate why you disagree on the contributing patches
> to libvirt approach and what the alternative approach do you propose?
>

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.


> Also, could you please elaborate on what is 'version of libvirt
> acceptable to Nova'? Cannot we just say that e.g. Nova requires libvirt
> X.Y to be deployed on FreeBSD?
>

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.

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.


> Anyway, speaking about FreeBSD support I assume we actually talking
> about Bhyve support. I think it'd be good to break the task and
> implement FreeBSD support for libvirt/Qemu first


 I believe Sean was referencing to Bhyve support, this is how I interpreted
it.


-- 
Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140716/d86fa517/attachment.html>