On 11/27/2013 01:32 PM, Rafał Jaworowski wrote: > On Mon, Nov 25, 2013 at 3:50 PM, Daniel P. Berrange <berra...@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).
Honestly... go the libvirt route, it's a lot simpler.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
