Open Stack

Excerpts from Jay Pipes's message of 2014-01-07 21:26:44 -0800:
> On Wed, 2014-01-08 at 17:20 +1300, Robert Collins wrote:
> > On 8 January 2014 12:18, James Slagle <james.slagle at gmail.com> wrote:
> > > Sure, the crux of the problem was likely that versions in the distro
> > > were too old and they needed to be updated.  But unless we take on
> > > building the whole OS from source/git/whatever every time, we're
> > > always going to have that issue.  So, an additional benefit of
> > > packages is that you can install a known good version of an OpenStack
> > > component that is known to work with the versions of dependent
> > > software you already have installed.
> > 
> > The problem is that OpenStack is building against newer stuff than is
> > in distros, so folk building on a packaging toolchain are going to
> > often be in catchup mode - I think we need to anticipate package based
> > environments running against releases rather than CD.
> 
> It's about matching the expectations of the end user (deployer). If they
> lean towards a CD model, then git based OpenStack deployments are
> clearly a necessity -- otherwise we'd need to maintain a set of package
> archives built (and tested!) for every project and every commit to
> master.
> 
> If they lean towards a more traditional release model, then OpenStack
> packages maintained (and tested!) by the distros are a better fit for
> the end user.
> 
> However...
> 
> Both camps should be able to experience the benefits of having an
> OpenStack undercloud building an OpenStack overcloud, without forcing
> the end user to adopt a methodology they may not yet be comfortable
> with.
> 

Jay's statements highlight that I have not been clear during this
thread. I don't mean to force any of the methods on anyone, and agree
with Jay that we should be able to leverage OpenStack to deploy OpenStack
in many different ways.

My reason for questioning the value of packages is that we have limited
resources, and I don't want to direct them toward an effort solely because
"thats what we've always done". I'm a packager myself, so there is this
desire, sometimes, to just go back to the tools I'm comfortable with.

But if there are developers who want and/or need to put time into using
packages then by all means, I welcome you with open arms. I think the
thread has proven to me that there is value in giving people the option
to use TripleO's tools with packages.

> As an aside, Fuel has an overcloud builder that uses Puppet to deploy
> OpenStack with packages [1]. I understand the Fuel dev team at Mirantis
> is keen to join forces with the Triple-O contributor community and
> reduce duplicative efforts. This may be the perfect place to pull some
> practices from Fuel to enable some flexibility in how
> tripleo-image-elements constructs things.
> 
> If you want a good indication of how much overlap there is, just look at
> the list of puppet modules in Fuel [2] vs. the list of elements in t-i-e
> [3].
> 

Nice comparison.

> Sure, t-i-e is Bash scripts and Fuel is Puppet manifests, but they are
> trying to do the same fundamental thing: produce an Overcloud entirely
> through automation. There are definite advantages to both approaches.
> Would be great to put our heads together and get the best of both
> worlds. I think the end user would benefit.
> 

Right, we are quite well aligned there. Where we run afoul of each
other is that Puppet is a religion, and thus Fuel's puppet pieces are
alienating the Chef believers. We'd rather not do that in TripleO.
Reminding myself of this is why I realize above that "not packages"
is also a religion, so I need to make sure I remain secular.

I think we should actually use this as an example of where to plug
Puppet in on top of the TripleO native tools which are emphatically not
ever going to be a replacement for Puppet beyond the minimal needed to
get a running, testable cloud.

And then perhaps the Chef clergy can do the same, and we'll have a nice
example of how to layer tools on top of TripleO's modular design.

> 
> [1] Just one example... here is the Glance installation by package:
> https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/glance/manifests/registry.pp#L76
> [2]
> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet
> [3]
> https://github.com/openstack/tripleo-image-elements/tree/master/elements
>