[openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Clint Byrum clint at fewbar.com
Wed Jan 8 02:39:24 UTC 2014

Excerpts from James Slagle's message of 2014-01-07 15:18:00 -0800:
> On Tue, Jan 7, 2014 at 6:04 PM, Clint Byrum <clint at fewbar.com> wrote:
> > Excerpts from Chris Jones's message of 2014-01-07 14:43:31 -0800:
> >> Hi
> >>
> >> > On 7 Jan 2014, at 22:18, Clint Byrum <clint at fewbar.com> wrote:
> >> > Packages do the opposite,
> >> > and encourage entropy by promising to try and update software
> >>
> >> Building with packages doesn't require updating running systems with packages and more than building with git requires updating running systems with git pull.
> >> One can simply build (and test!) a new image with updated packages and rebuild/takeover nodes.
> >>
> >
> > Indeed, however one can _more_ simply build an image without package
> > tooling...  and they will be more similar across multiple platforms.
> >
> > My question still stands, what are the real advantages? So far the only
> > one that matters to me is "makes it easier for people to think about
> > using it."
> I'm reminded of when I first started looking at TripleO there were a
> few issues with installing from git (I'll say that from now on :)
> related to all the python distribute -> setuptools migration.  Things
> like if you're base cloud image had the wrong version of pip you
> couldn't migrate to setuptools cleanly.  Then you had to run the
> setuptools update twice, once to get the distribute legacy wrapper and
> then again to latest setuptools.  If I recall there were other
> problems with virtualenv incompatibilities as well.
> Arguably, installing from packages would have made that easier and less complex.

No argument, it would have been easier. But it would not have been less
complex. The complexity would have been obscured.

It really would have just deferred the problem to the distro. That may
be a good thing, as the distro knows how to solve its own problems. But
then Fedora solves it, and Ubuntu solves it, and Debian solves it...

Or, OpenStack solves it, once, and OpenStack's users roll on no matter
what they choose for distro.

> Sure, the crux of the problem was likely that versions in the distro
> were too old and they needed to be updated.  But unless we take on
> building the whole OS from source/git/whatever every time, we're
> always going to have that issue.  So, an additional benefit of
> packages is that you can install a known good version of an OpenStack
> component that is known to work with the versions of dependent
> software you already have installed.

I disagree on the "all or nothing" argument. We can have a pre-packaged OS
that implements stable interfaces like POSIX, python-2.7 and even "git",
and we can have a fast moving application like OpenStack riding on top
of that in a self contained application container like a virtualenv or
even a Docker container.

The Linux distro model is _really_ good at providing an OS, tools and
libraries. I am not so convinced that the distro model is actually
any good for providing applications. I say that as one of the current
maintainers of MySQL, which mixes libraries and applications, in Debian.

The pain that the MySQL packaging team goes through just to have the thing
work similar to postgresql and apache is a little bit crazy-inducing,
so please excuse me when I shake up the bottle and spray crazy all over
the list. :)

Also, "known good" is incredibly subjective, as "good" implies a set
of expectations that are being met. But whatever that "good" means is
fairly poorly defined and probably not automated. :P

More information about the OpenStack-dev mailing list