Hi My guess for the easiest answer to that: distro vendor support.
Cheers, -- Chris Jones > On 7 Jan 2014, at 20:23, Clint Byrum <cl...@fewbar.com> wrote: > > 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. >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
