Open Stack

----- Original Message -----
> From: "Clint Byrum" <clint at fewbar.com>
> To: "openstack-dev" <openstack-dev at lists.openstack.org>
> Sent: Tuesday, January 7, 2014 3:23:24 PM
> Subject: Re: [openstack-dev] [TripleO] Installing from packages in	tripleo-image-elements
> 
> 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. :)

To be clear James is talking initially about using packages to build images (not update them at runtime).

In any case for much the same reason I look at what we do today with the source based pip installs an an entropy bomb:

-multiple venvs in the same image
-each venv contains its own copies of libraries
-everything is compiled on the fly
-due to the above ^^ image builds often fail!!!

I'd expect that anyone using real packages for OpenStack element has much less entropy on many fronts:

-more control over what is installed
-faster image build times
-less duplication

The cost when using real packages is maintaining them. But once you have that (which we will)... you've got a lot more control over things.


> 
> [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.
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>