[Openstack] Issues with Packaging and a Proposal

Thierry Carrez thierry at openstack.org
Thu Aug 25 07:52:05 UTC 2011


What a good way to start a long milestone release day.

Disclaimer: I used to work for Canonical as the Technical Lead for
Ubuntu Server -- and I'm now OpenStack Release Manager.

Like Monty said, this is not the first time the "integrated
distribution" model conflicts with deployers needs. This has been
discussed quite a few times already, and I happen to know the subject
quite well.

Integrated distributions (think Debian or Ubuntu) want you to run the
pristine packages in their official repositories. They don't want you to
run your own (and submit bugs when it fails), they don't want you to run
a custom backport of a required new library. They want you to stay with
a given version on a given OS, and to upgrade the whole package from
time to time (Note: This does not affect that much RPM-based
distributions, where taking a random RPM from a vendor site is
apparently more accepted, due to most packages missing from the distro
anyway).

Deployers want to be able to run the exact version they want, on the
exact OS they want. Use the base packages in the OS from a given
reference point (generally Debian stable or Ubuntu LTS), and then deploy
key packages at a chosen version, along with any dependency.

Those goals are not compatible.

So far we tried to reach both targets. We tightly integrated with the
Ubuntu release under development. The absence of territorial
maintainership in Ubuntu allowed us to efficiently push patches or bump
versions on dependencies so that the future Ubuntu release would have
all we need, and OpenStack packages could run directly on the pristine
OS. We aligned the release schedules so that Ubuntu could actually ship
the latest version of OpenStack packages in their official repositories.
For all the other use cases, we would provide PPAs (last release, last
milestone, trunk) x (lucid, maverick, natty, oneiric).

This is very elegant, especially for ex-Ubuntu developers now working on
upstream, like Soren or me. But I agree it has a few drawbacks, due to
the fact it's pretty centered around Ubuntu: it makes the other distros
second-class citizens, and it makes the "deployer" use case above a
second-class citizen as well.

The end result being that some critical deployers ended up not using our
packages. We can bitch forever how wrong that is, and what they should
do instead -- I don't think we'll change them. Monty's proposal is
trying to address that.

I think his proposal makes sense, but I also see how much we'll lose if
we follow it. Reading between the lines, Monty's proposal is about
losing the Ubuntu-integrated development, and providing our own packages
(+ any needed dep) in our own repositories for a set of supported
platforms. Then distributions are free to try to take those packages and
ship them in their own repositories, or not.

The first and most immediate drawback in my opinion is that we lose the
very experienced Debian packaging team that we had set up. By closely
working with Ubuntu upstream, we could leverage their manpower and
experience to benefit our packaging. Bugs reported against Ubuntu
packaging were in fact reported against our common work, and we got
their bugfixes for free. If we move forward with this plan, the Ubuntu
devs will retreat into being pure consumers (like with every other
upstream), adding patches for their needs in their own version of the
packaging. It's a loss that shouldn't be underestimated, especially by
people that so far contributed nothing to the existing packaging.

The second drawback is that without integration, the incentive to make
the environments converge is limited. So far when we added a dependency
there were discussions with Ubuntu as to what the common version should
be. Now OpenStack will just pick what it prefers and shove it into its
repos. Using packages from official repositories is more stable: their
combination with the OS is more tested, and we benefit from OS bugfixes.
So I expect the end result will be a less-integrated and more buggy
environment.

The last (and not least) drawback is that by following this plan, we
become distributors. That means we have to care about support
timeframes, point releases and security updates. We can no longer
pretend that the downstream distributions will do it for us. This is a
huge undertaking... who exactly is going to do that maintenance ? Is it
really the best way to spend our time ?

Last remark, to my fellow Frenchman Thomas, who sounds very supportive
of Monty's proposal: I'm far from certain the end result would simplify
your life. You'll still have to chase all dependency maintainers so that
they align their version and patches with the ones OpenStack will
require. Debian's use case is the same as Ubuntu's above -- you want
people to use the main repository. Having an upstream ship its own
overlapping debs should scare you. Unless your personal need, as an
OpenStack user, is more on the deployer use case ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack




More information about the Openstack mailing list