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 <jaypi...@gmail.com> wrote: > > > On 08/19/2014 11:28 PM, Robert Collins wrote: > > > >> On 20 August 2014 02:37, Jay Pipes <jaypi...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
