Open Stack

Hi Soren,

On Wed, 2011-08-24 at 22:11 +0200, Soren Hansen wrote:
> 2011/8/24 Monty Taylor <mordred at inaugust.com>:
> > - Lack of RPM support. Turns out RPM distros are still kind of popular,
> > and at least one of our major contributors (hi, NTT) rolls out on
> > RHEL/CentOS, and one of our partners who is going to be contributing
> > testing hardware (MSFT/Novell) is associated with a distro (SuSE) that
> > is RPM based. We're a few steps away from this, but it warrants mentioning.
> 
> This probably warrants a separate discussion. As pointed out further
> up, Ubuntu was chosen in part because it's very up-to-date. With a
> release every 6 months, we're never far behind in terms of access to
> dependencies in the most recent release, and since our release cycles
> line up, we can *ensure* availability of the dependencies we require
> in the upcoming release.  If
> RHEL/CentOS/ScientificLinux/WhatEverOtherFlavourOfRedHatYouPrefer
> becomes a supported target, will this block stuff from landing in Nova
> until RHEL catches up with the rest of the world in terms of libraries
> upon which we depend?

Absolutely not. Upstream needs to continue adopting the latest version
of dependencies. It's up to the distributions to deal with the fallout.

I expect the latest Fedora release would be a similar enough target (in
terms of dependency versions) for upstream development as the latest
Ubuntu release.

Indeed, while packaging Diablo for Fedora 16[1] some of the problems
I've hit so far are due to OpenStack upstream using older versions of
dependencies than Fedora 16 ships with e.g.

  * A couple of migrations fail with SQLAlchemy 0.7.x - I've proposed a 
    merge with fixes for that

  * M2Crypto 0.20.2 doesn't build against latest openssl headers (e.g. 
    STACK macro changed to STACK_OF) but OpenStack seems to work just 
    fine with 0.21.1 - this just means that install_venv.sh doesn't 
    work on Fedora 16


I don't know the background to this whole thread, but IMHO:

  * Upstream core devs shouldn't need to worry much about packaging, for
    any distro. Given the upstream use of virtualenv, the policy for 
    dependencies should be just to use the latest and greatest. For 
    non-python dependencies (e.g. iptables, libvirt, KVM, Xen) there 
    should probably only be versions from a limited set of fast moving
    distros supported.

  * Packaging for multiple distros is tough - RHEL6 was based on F13, 
    but, with e.g. the switch to systemd, I'd hate to be the guy trying 
    to maintain packaging for both. Nevermind adding packaging for 
    OpenSuse into the mix.

  * There seems to be demand from various folks deploying OpenStack 
    (e.g. Rackspace, Grid Dynamics, Mirantis) for regular builds of the
    development branch for different distros. Is there also demand for 
    the bits to be packaged differently - e.g. with different defaults?

    I guess there'll always be some demand for builds like these, but
    perhaps it will lessen as the project matures and distros own
    packaging of OpenStack improves?

  * The project doesn't necessarily need to release official packages as
    part of the project release. If it does, it should limit them to 
    the limited set of fast moving distros.

  * The project should be cautious about what expectations it sets for
    the longer term and how it commits its resources. For example, if I
    set up a Jenkins job to build Fedora 16 packages of trunk, the 
    project shouldn't be quick to bless those as official and set the 
    expectation that such packages will always be available.

  * Open upstream co-operation between anyone doing packaging is great. 
    The Packaging wiki page is an awesome idea. Maybe an 
    openstack-packagers list would be the next step. Maybe bring all 
    (mirrors of?) the packaging SCMs together in an openstack-packaging
    github organization. But this is about sharing knowledge, not so 
    much about sharing work on a common upstream.

Meh, sorry if this was tl;dr :)

Cheers,
Mark.

[1] - http://lists.fedoraproject.org/pipermail/cloud/2011-August/000733.html