Open Stack

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.

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].

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.

All the best,
-jay

[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