Open Stack

On Wed, Nov 27, 2013 at 05:29:35PM -0500, Sean Dague wrote:
> On 11/27/2013 01:32 PM, Rafał Jaworowski wrote:
> > On Mon, Nov 25, 2013 at 3:50 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> >> On Fri, Nov 22, 2013 at 10:46:19AM -0500, Russell Bryant wrote:
> >>> On 11/22/2013 10:43 AM, Rafał Jaworowski wrote:
> >>>> Russell,
> >>>> First, thank you for the whiteboard input regarding the blueprint for
> >>>> FreeBSD hypervisor nova driver:
> >>>> https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node
> >>>>
> >>>> We were considering libvirt support for bhyve hypervisor as well, only
> >>>> wouldn't want to do this as the first approach for FreeBSD+OpenStack
> >>>> integration. We'd rather bring bhyve bindings for libvirt later as
> >>>> another integration option.
> >>>>
> >>>> For FreeBSD host support a native hypervisor driver is important and
> >>>> desired long-term and we would like to have it anyways. Among things
> >>>> to consider are the following:
> >>>> - libvirt package is additional (non-OpenStack), external dependency
> >>>> (maintained in the 'ports' collection, not included in base system),
> >>>> while native API (via libvmmapi.so library) is integral part of the
> >>>> base system.
> >>>> - libvirt license is LGPL, which might be an important aspect for some users.
> >>>
> >>> That's perfectly fine if you want to go that route as a first step.
> >>> However, that doesn't mean it's appropriate for merging into Nova.
> >>> Unless there are strong technical justifications for why this approach
> >>> should be taken, I would probably turn down this driver until you were
> >>> able to go the libvirt route.
> >>
> >> The idea of a FreeBSD bhyve driver for libvirt has been mentioned
> >> a few times. We've already got a FreeBSD port of libvirt being
> >> actively maintained to support QEMU (and possibly Xen, not 100% sure
> >> on that one), and we'd be more than happy to see further contributions
> >> such as a bhyve driver.
> > 
> > As mentioned, in general we like the idea of libvirt bhyve driver, but
> > sometimes it may not fit the bill (licensing, additional external
> > dependency to keep track of) and hence we consider the native option.
> > 
> >> I am of course biased, as libvirt project maintainer, but I do agree
> >> that supporting bhyve via libvirt would make sense, since it opens up
> >> opportunities beyond just OpenStack. There are a bunch of applications
> >> built on libvirt that could be used to manage bhyve, and a fair few
> >> applications which have plugins using libvirt
> > 
> > Could you perhaps give some pointers on the libvirt development
> > process, how to contribute changes and so on?
> > 
> > Another quick question: for cases like this, how does Nova manage
> > syncing with the required libvirt codebase when a new hypervisor
> > driver is added or for similar major updates happen?
> > 
> >> Taking on maint work for a new OpenStack driver is a non-trivial amount
> >> of work in itself. If the burden for OpenStack maintainers can be reduced
> >> by, pushing work out to / relying on support from, libvirt, that makes
> >> sense from OpenStack/Nova's POV.
> > 
> > The maintenance aspect and testing coverage are valid points, on the
> > other hand future changes would have to go a longer way for us: first
> > upstream to libvirt, then downstream to the FreeBSD ports collection
> > (+ perhaps some OpenStack code bits as well), which makes the process
> > more complicated.
> 
> I think you also need to weigh that against the CI requirements for
> landing a driver in tree for nova, which is probably a dedicated rack of
> hardware running the zuul infrastructure reporting back success / fail
> results on every proposed nova patch. Made more complicated if your
> hypervisor doesn't nest (I have no idea if this one does).

NB, technically we should have separate CI running for each hypervisor
that libvirt is able to talk to, so there'd likely want to be dedicated
CI infrastructure for the libvirt+bhyve combination regardless, perhaps
it would need less overall though.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|