[openstack-dev] [nova] FreeBSD host support, round 2
novel at FreeBSD.org
Fri Jun 12 13:36:04 UTC 2015
Daniel P. Berrange wrote:
> On Tue, Jun 09, 2015 at 07:52:39PM +0300, Roman Bogorodskiy wrote:
> > Hi,
> > Few months ago I've started a discussion on FreeBSD host support for
> > OpenStack.  At a result of discussion it was figured out that there
> > are a number of limitations, mainly on the BHyVe (the FreeBSD hypervisor)
> > side, that make the effort not feasible.
> Do you still intend to add the missing features to BHyve to let it be
> supported in Nova eventually too ?
As I don't take part in bhyve development, it's hard for me to give a
detailed answer on that. I know that bhyve developers are
planning/working on some important improvements like UEFI support,
moving to single step guest boot and some others. I'm just trying to
keep libvirt/bhyve driver up to date.
> > However, some things changed since then. Specifically, FreeBSD's got Xen
> > dom0 support.  In context of OpenStack deployment that has a number of
> > benefits over bhyve. Specifically:
> > * The stack is more mature and feature-rich
> > * The toolstack is here already: libxl is available through the FreeBSD
> > ports tree, libvirt/libxl works there with minimal modifications
> > (already available in the git master)
> > * OpenStack libvirt/libxl driver is already here
> > I was able to setup a proof-of-concept environment on FreeBSD that
> > required quite a small amount of modifications required in OpenStack:
> > * Glance and Keystone didn't require any changes
> > * Nove required some minor modifications mainly in the linux_net.py
> > area
> > The summary of Nova modifications:
> > * I had to implement FreeBSD version of linux_net.LinuxNetInterfaceDriver.
> > It currently doesn't support vlans though.
> > https://github.com/novel/bsdstack/blob/master/bsdstack/nova/network/freebsd_net.py
> > I keep it as an external package and configure Nova to use it through
> > linuxnet_interface_driver config option in nova.conf
> > * I had to create a stub for the IptablesManager class. I also had to
> > add a config option to be able to override class for that in a way
> > similar to interface driver.
> > * I had to fix a minor interface incapability for NullL3 stub, that's
> > already in the Nova tree: https://review.openstack.org/#/c/189001/
> > * I added a hack to use 'phy' driver in domain's xml for disks because
> > for some reason driver='qemu' results in guests not able to access
> > disk devices (tried both FreeBSD and Linux guests). Need to
> > investigate
> > * Dropped some LinuxBridgeInterfaceDriver hardcodes in
> > virt.libvirt.vif.
> > Here's a quick overview of my changes:
> > https://github.com/novel/nova/compare/stable/kilo...novel:stable/kilo_freebsd?expand=1
> > With this changes I was able to get things working, i.e. VM starting,
> > obtaining IP addresses (with nova-network configured with FlatDHCP) etc.
> > Having that said I'm wondering if community is interested in integrating
> > FreeBSD support through libvirt/libxl into mainline? Obviously, the
> > changes I provided are shortcuts and the appropriate specs should be
> > create with proposals of proper designs, not quick hacks like that.
> I'd be happy to see FreeBSD support for any of the libvirt hypervisors
> added to Nova. As you point out, the changes to the libvirt code are
> going to be pretty minimal for libxl, so there's not going to be any
> appreciable ongoing maint burden for this. So I see no serious reason
> to reject the changes to Nova libvirt driver code for libxl+FreeBSD.
> The fun bit will be the changes to non-libvirt code in nova...
> > The biggest part of the unportable code, just like it was in bhyve case,
> > is still linux_net.py, so probably it makes sense to revive the old
> > spec:
> > https://review.openstack.org/#/c/127827/
> > TBH, IMHO linux_net.py could have a refactor regardless of FreeBSD
> > support. It's approx. 2000 lines long, contains a lot of stuff like
> > dnsmasq handling code, interface handing code and firewall management
> > that could have their own place.
> Yes, that network setup code is really awful and I'd love to see
> it refactored regardless of FreeBSD support.
> With my crystal ball, probably the main question wrt any kind of
> FreeBSD support will be that of 3rd party CI testing. I don't know
> whether there is any company backing your work who has resources
> to provide a CI system, or whether FreeBSD project can manage it
> independently ?
I do all my FreeBSD related activities in my free time, in other words
it's not backed by any company. Anyway, I think it would not be a
problem to arrange virtual machines for running unit tests. As for
integration testing it's going to be harder because it'd need a real
hardware and I need to figure out how I could obtain one.
> The refactoring of the linux_net.py code could be done even without
> CI support of course - that would only block the second part where
> you actually add a FreeBSD implementation
That sounds good. I'll create a new spec for linux_net.py refactoring
As a parallel activity, I'll try to create a CI that would run only unit
tests for the key projects at this point. There are some issues with
that as well, because I have to install some patched versions of the
packages that are not usable as is from pypi.
That sounds like a realistic plan for Liberty to me. If this proofs
itself viable, I guess it'd be time to look into setting up integration
tests and pushing the actual FreeBSD code for the M-release.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: not available
More information about the OpenStack-dev