Let me quote the pertinent part from Luke’s mail:

DavidS wrote:

• Create a new github account to collect all modules with a repo per module.
• Add devs as available to the modules/repos as collaborators to allow them to push changes.
• Use the issue tracker attached to each module for bug tracking.
• Use a meta-repo to combine “matching” module versions into “releases”.
• Encourage wide-spread collaboration.

I’m willing to do all the necessary legwork to set this up. Just say the word.

That’s basically the plan. If you make a ‘puppet-modules’ account and want to set it up… That would be awesome.

So there we go, I’ve created a puppet-modules account on github where useful and maintained repos can be published. To seed the effort I’ve already committed a few of my core modules and expect to add some more at a later time when the workflow is settled in.

The primary entry point for local perusal is the puppet-manifests repository which contains all others as submodules. This is very convenient to clone all modules at once:

$ git clone git://github.com/puppet-modules/puppet-manifests.git
$ cd puppet-manifests/
$ git submodule init
$ git submodule update

Within modules/ you can now find git repositories for all published modules, ready to go.

For working on the repos, I’ve created forks of all modules in my private github account to avoid cluttering the “published” versions.

If you have any patches or modules to contribute or want to collaborate, please use github’s issue tracker of the concerned module or send a shout to puppet-users or me privately.

Puppet doesn’t care whether it manages one or a hundred servers with the same configuration. Contrary to manual configuration, the effort scales with the number of programmed services instead of the number of administrated servers.

Another important factor is the organisation of configuration into modules. These can be developed, tested and deployed independently. David runs the first and one of the biggest public repositories of such modules under the very liberal BSD-License. Thanks to my engagement in the puppet community I was recently asked by multiple IT-departments to hold on-site trainings.

Finally it has to be noted that a manifest (puppet configuration) is a very detailed documentation of the (intended) system state.

David uses puppet for EDV-Beratung&Service to run a web- and mail hosting system. Before the advent of puppet, each customer was configured manually, leading to all kind of errors. With puppet any error gets fixed once and for all by improving the source code of the puppet manifest. Additionally this will also fix the problem on all existing customers.