----- Original Message ----- > From: "Clint Byrum" <[email protected]> > To: "openstack-dev" <[email protected]> > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
