Open Stack

Excerpts from Jan Provaznik's message of 2014-01-08 03:00:19 -0800:
> On 01/07/2014 09:01 PM, James Slagle wrote:
> > 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.
> >
> 
> Hi James,
> I think it would be really nice to be able install openstack+deps from 
> packages and many users (and cloud providers) would appreciate it.
> 
> Among other things, with packages provided by a distro you get more 
> stability in compare to installing openstack from git repos and fetching 
> newest possible dependencies from pypi.
> 
> In a real deployment setup  I don't want to use "more-than-necessary" 
> newer packages/dependencies when building images - taking an example 
> from last days I wouldn't have to bother with newer pip package which 
> breaks image building.
> 

Right, from this perspective, you want to run OpenStack stable releases.
That should be fairly simple now by building images using the appropriate
environment variables.

However, we don't test that so it is likely to break as Icehouse diverges
from Havana. So I think in addition to package-enabling, those who want
to see TripleO work for stable releases should probably start looking at
creating stable branches of t-i-e and t-h-t to build images and templates
from starting at the icehouse time-frame.

So given that I'd suggest that packages take a back seat to making
TripleO part of the integrated release of OpenStack. Otherwise we'll
just have stable releases for the distros who have packages that work
with TripleO instead of for all distros.