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 <berra...@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 :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
