Open Stack

Hi

My guess for the easiest answer to that: distro vendor support.

Cheers,
--
Chris Jones

> On 7 Jan 2014, at 20:23, Clint Byrum <clint at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev