On 08/22/2014 01:30 AM, Michael Chapman wrote: > > > > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes <jaypi...@gmail.com > <mailto: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 > <mailto: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. > > In addition and perhaps as a consequence, there isn't any public > integration testing at this time for the modules, although I know some > parties have developed and maintain their own. > > The Chef modules may be in a different state, but it's hard for me to > recommend the Puppet modules become part of an official program at this > stage.
Is the focus of the Puppet modules only stable releases with packages? Puppet + git based deploys would be honestly a really handy thing (especially as lots of people end up having custom fixes for their site). The lack of CM tools for git based deploys is I think one of the reasons we seen people using DevStack as a generic installer. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev