nova team mailing list archive

[Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx>]

Perhaps I can propose an alternative statement, having thought about this a
bit more:

The OpenStack project / organisation will only be responsible for maintaining /
testing OpenStack on a selected set of dependencies (which are likely to be
nearer to "latest and greatest" than "long-term stable").  OpenStack releases
will be with respect to that baseline.

If someone wants OpenStack to work on something older, then they'd be
responsible for making that happen (and patches that didn't adversely affect
OpenStack's architectural integrity would be welcome).

So for example, if Novell want to package OpenStack for SUSE, and SLES was
lagging behind the latest version of Python, then they'd be responsible for
fixing up any issues.  Ditto Citrix if XenServer lags.

Does that better suit the kind of thing that people are aiming for?  It's
similar to how the Xen community works: Xen.org makes releases that are
then stabilized by Novell into SUSE, Citrix into XenServer, etc.  It
becomes the responsibility of the distro if there's a software version
conflict that needs sorting out.

How does that sound?  Does that give OpenStack the flexibility it needs to
keep pressing forward, without being burdened by backwards compatibility
issues?

Cheers,

Ewan.

On Wed, Sep 29, 2010 at 10:03:38AM +0100, Joshua McKenty wrote:

> This seems somewhat tangential to me (from the Python debate), since Swift
> needs to run on bare metal regardless. I like it as a goal, but I think
> the volume controller is a second point of issue (although to be honest I
> haven't followed a lot of the recent work in that area) - although it's
> possible to remote LVM calls, I think driving iSCSI or AoE that way will
> need to be carefully managed.
> My biggest concern would to make it clear (in deployment guides,
> tutorials, etc) that Nova shouldn't be run in the same virtualization
> environment as the one that it's CONTROLLING. (For what I hope are obvious
> reasons.)
> Joshua
> 
> On Wed, Sep 29, 2010 at 3:35 AM, Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx>
> wrote:
> 
>   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.
> 
>   _______________________________________________
>   Mailing list: https://launchpad.net/~nova
>   Post to     : nova@xxxxxxxxxxxxxxxxxxx
>   Unsubscribe : https://launchpad.net/~nova
>   More help   : https://help.launchpad.net/ListHelp