Open Stack

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).

Honestly... go the libvirt route, it's a lot simpler.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131127/b9a59b8f/attachment.pgp>