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

Clint Byrum clint at fewbar.com
Tue Jan 7 20:23:24 UTC 2014


What would be the benefit of using packages?

We've specifically avoided packages because they complect[1] configuration
and system state management with software delivery. The recent friction
we've seen with MySQL is an example where the packages are not actually
helping us, they're hurting us because they encode too much configuration
instead of just delivering binaries.

Perhaps those of us who have been involved a bit longer haven't done
a good job of communicating our reasons. I for one believe in the idea
that image based updates eliminate a lot of the entropy that comes along
with a package based updating system. For that reason alone I tend to
look at any packages that deliver configurable software as potentially
dangerous (note that I think they're wonderful for libraries, utilities,
and kernels. :)

[1] http://www.infoq.com/presentations/Simple-Made-Easy

Excerpts from James Slagle's message of 2014-01-07 12:01:07 -0800:
> Hi,
> 
> I'd like to discuss some possible ways we could install the OpenStack
> components from packages in tripleo-image-elements.  As most folks are
> probably aware, there is a "fork" of tripleo-image-elements called
> tripleo-puppet-elements which does install using packages, but it does
> so using Puppet to do the installation and for managing the
> configuration of the installed components.  I'd like to kind of set
> that aside for a moment and just discuss how we might support
> installing from packages using tripleo-image-elements directly and not
> using Puppet.
> 
> One idea would be to add support for a new type (or likely 2 new
> types: rpm and dpkg) to the source-repositories element.
> source-repositories already knows about the git, tar, and file types,
> so it seems somewhat natural to have additional types for rpm and
> dpkg.
> 
> A complication with that approach is that the existing elements assume
> they're setting up everything from source.  So, if we take a look at
> the nova element, and specifically install.d/74-nova, that script does
> stuff like install a nova service, adds a nova user, creates needed
> directories, etc.  All of that wouldn't need to be done if we were
> installing from rpm or dpkg, b/c presumably the package would take
> care of all that.
> 
> We could fix that by making the install.d scripts only run if you're
> installing a component from source.  In that sense, it might make
> sense to add a new hook, source-install.d and only run those scripts
> if the type is a source type in the source-repositories configuration.
>  We could then have a package-install.d to handle the installation
> from the packages type.   The install.d hook could still exist to do
> things that might be common to the 2 methods.
> 
> Thoughts on that approach or other ideas?
> 
> I'm currently working on a patchset I can submit to help prove it out.
>  But, I'd like to start discussion on the approach now to see if there
> are other ideas or major opposition to that approach.
> 



More information about the OpenStack-dev mailing list