Open Stack

Excerpts from Michael Chapman's message of 2014-08-21 23:30:44 -0700:
> On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
> > On 08/19/2014 11:28 PM, Robert Collins wrote:
> >
> >> On 20 August 2014 02:37, Jay Pipes <jaypipes at gmail.com> wrote:
> >> ...
> >>
> >>  I'd like to see more unification of implementations in TripleO - but I
> >>>> still believe our basic principle of using OpenStack technologies that
> >>>> already exist in preference to third party ones is still sound, and
> >>>> offers substantial dogfood and virtuous circle benefits.
> >>>>
> >>>
> >>>
> >>> No doubt Triple-O serves a valuable dogfood and virtuous cycle purpose.
> >>> However, I would move that the Deployment Program should welcome the many
> >>> projects currently in the stackforge/ code namespace that do deployment
> >>> of
> >>> OpenStack using traditional configuration management tools like Chef,
> >>> Puppet, and Ansible. It cannot be argued that these configuration
> >>> management
> >>> systems are the de-facto way that OpenStack is deployed outside of HP,
> >>> and
> >>> they belong in the Deployment Program, IMO.
> >>>
> >>
> >> I think you mean it 'can be argued'... ;).
> >>
> >
> > No, I definitely mean "cannot be argued" :) HP is the only company I know
> > of that is deploying OpenStack using Triple-O. The vast majority of
> > deployers I know of are deploying OpenStack using configuration management
> > platforms and various systems or glue code for baremetal provisioning.
> >
> > Note that I am not saying that Triple-O is bad in any way! I'm only saying
> > that it does not represent the way that the majority of real-world
> > deployments are done.
> >
> >
> > > And I'd be happy if folk in
> >
> >> those communities want to join in the deployment program and have code
> >> repositories in openstack/. To date, none have asked.
> >>
> >
> > My point in this thread has been and continues to be that by having the TC
> > "bless" a certain project as The OpenStack Way of X, that we implicitly are
> > saying to other valid alternatives "Sorry, no need to apply here.".
> >
> >
> >  As a TC member, I would welcome someone from the Chef community proposing
> >>> the Chef cookbooks for inclusion in the Deployment program, to live under
> >>> the openstack/ code namespace. Same for the Puppet modules.
> >>>
> >>
> > While you may personally welcome the Chef community to propose joining the
> > deployment Program and living under the openstack/ code namespace, I'm just
> > saying that the impression our governance model and policies create is one
> > of exclusion, not inclusion. Hope that clarifies better what I've been
> > getting at.
> >
> >
> 
> (As one of the core reviewers for the Puppet modules)
> 
> Without a standardised package build process it's quite difficult to test
> trunk Puppet modules vs trunk official projects. This means we cut release
> branches some time after the projects themselves to give people a chance to
> test. Until this changes and the modules can be released with the same
> cadence as the integrated release I believe they should remain on
> Stackforge.
> 

Seems like the distros that build the packages are all doing lots of
daily-build type stuff that could somehow be leveraged to get over that.