Comment inline. On Aug 22, 2014, at 10:13 AM, Michael Chapman <wop...@gmail.com> wrote:
> > > > On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague <s...@dague.net> wrote: > 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? > > > We try to target puppet module master at upstream OpenStack master, but > without CI/CD we fall behind. The missing piece is building packages and > creating a local repo before doing the puppet run, which I'm working on > slowly as I want a single system for both deb and rpm that doesn't make my > eyes bleed. fpm and pleaserun are the two key tools here. > > 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. > > > It's possible but it's also straight up a poor thing to do in my opinion. If > you're going to install nova from source, maybe you also want libvirt from > source to test a new feature, then you want some of libvirt's deps and so on. > Puppet isn't equipped to deal with this effectively. It runs yum install x, > and that brings in the dependencies. > > It's much better to automate the package building process and install > everything using that single method. Otherwise the operations team now has to > consider which dependencies have come from pip, and which have come from > deb/rpm. A couple projects (stackforge or other) that do just this... http://anvil.readthedocs.org/en/latest/topics/summary.html#summary https://github.com/openstack-packages/delorean I've been in talk with the delorean folks and we are working to try to unify/combine/merge or other the above 2 projects. The first (anvil) yahoo and godaddy have been using to build icehouse, havana (folsom I believe we used it for also) for over a year now into rpm packages (with any custom packages we want), Delorean I think has been getting used in triple-o for a similar purpose. -Josh > > -Sean > > -- > Sean Dague > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
