nova team mailing list archive

[Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx>]

I saw the Python 2.5 vs 2.6 debate in the release meeting today.  I don't
want to weigh into that directly, but I want to propose an alternative
design tenet:

  It should always be possible to run Nova in a virtual appliance.

As long as we stick to this as a requirement, then we don't need to worry
so much about version skew between dependencies, because Nova's requirements
can be isolated from the base platform.

creiht is completely correct when he says that these battles can be very hard
and fruitless, and we shouldn't try to fight them.  For example, the XenServer
domain 0 userspace still has Python 2.4, never mind 2.5.  There's no way that
you can say to a large cloud provider "You know that one upgrade per year that
you have planned?  Well you've got to make sure that the virt layer you're
spending all that money on has support for all these new dependencies too."

That's an impossible battle, but as long as Nova can run in virtual appliances,
then we don't need to go there, and we can have whatever dependencies we
want pretty much.

I think that we're nearly there in this regard.  libvirt can remote its
calls into the virt platform, as can XenAPI.  The only thing that's concerning
right now is the network layer, which seems to want to do all sorts of
dnsmasq and iptables things, as if it's guaranteed to be running in domain 0.
That looks like it needs some rearchitecting (or a different driver, parallel
with linux_net) in order to fit this model.

Note that I'm not suggesting that Nova _must_ run in a virtual appliance.  As
I understand it, the normal deployment model for SUSE Xen or KVM would be to
have a "full" control domain with all the control software in it, as opposed
to the "appliance" or "disaggregated" model that we're aiming for with
Xen Cloud Platform and XenServer.

Does anyone object to this?  Can we adopt this as a long-term design goal?

Thanks,

Ewan.