Open Stack

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.

Rafal