openstack team mailing list archive
Mailing list archive
Re: Issues with Packaging and a Proposal
On Wed, 2011-08-24 at 22:11 +0200, Soren Hansen wrote:
> 2011/8/24 Monty Taylor <mordred@xxxxxxxxxxxx>:
> > - 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
> 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
Indeed, while packaging Diablo for Fedora 16 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
* 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 :)
 - http://lists.fedoraproject.org/pipermail/cloud/2011-August/000733.html