Open Stack

On Wed, Nov 27, 2013 at 07:32:13PM +0100, Rafał Jaworowski wrote:
> On Mon, Nov 25, 2013 at 3:50 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > 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?

The libvirt development process is follows a time-based release cycle.
We aim to release once a month, on/near the 1st of the month to ensure
there's always fast turn around for user delivery once a feature is
merged.

We of course use GIT for development but in constrast to OpenStack we
follow a traditional mailing list based workflow. We recommend that
people use 'git send-email' to submit patch(-series) against the
libvirt GIT master branch. We don't require any kind of CLA to be
signed - people can just jump right in and contribute. There is some
more guidance on general development practices here

  http://libvirt.org/hacking.html

Before starting on a major dev effort we'd recommend people join the
main dev mailing list and just outline what they want to achieve, so
we can give early feedback and/or assistance. 

  http://libvirt.org/contact.html

If you want to get into nitty-gritty of how to actually write a new
hypervisor driver in libvirt, we should probably move the conversation
to the libvirt list.

> 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?

Nova declares a minimum required libvirt version, currently 0.9.6
but with a patch pending to increase this to 0.9.11. This is mostly
about ensuring a core feature set is available. Any given libvirt
hypervisor driver may decline to implement any feature it wishes.
So there are also version checks done for specific features, or a
feature may be blindly used and any exception reported is handled
in some way.

For the current Libvirt drivers (xen/lxc/qemu/kvm) we look at what
Linux distros have which versions when deciding what is reasonable
version to mandate

  https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix

periodically we'll re-examine the distros to see if there's a reason
to update the min required libvirt. Currently we don't distinguish
different libvirt versions for different hypervisors, but there's
no reason we shouldn't do that.

So if you were to write a bhyve driver for libvirt, then we'd end
up adding a specific version check to Nova that mandates use of
a suitably new libvirt version with that HV platform.

Regards,
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 :|