Puppet modules organization

[Ewoud Kohl van Wijngaarden]

On Tue, Jun 17, 2014 at 11:36:35AM +0200, David Caro wrote:
> Hi everyone!
> 
> I'm starting a thread to discuss the puppet modules organization.
> 
> There are two proposed ways of organizing them:
> 
> 1.- Using a unique module named ovirt_infra
> 2.- Using multiple modules, named ovirt_*
> 
> Feel free to propose other alternatives, the main points for each one are:
> 
> 1.- Everything inside one module, easy to find
> 1.- Easy to add a new class, just create the file
> 1.- Easy to create hard to maintain code
> 1.- Easy to create very interdependent code
> 
> 
> 2.- Enforces modularization of the different code (one module, one task), that
> brings
> 2.- Easier to test
> 2.- Safe to reuse
> 2.- More organized (not everything in the same place)
> 2.- It's the most common way of organizing puppet manifests, so the main
> guidelines, patterns and most of the documentation expects this way of working.
> 
> 
> Please send your comments and if too many I'll open a pad with the them for easy
> review.
> 
> 
> I vote for #2, modularized organization.

I'd be in favor of a roles/profiles pattern[1]. Given we use foreman, I
think the roles pattern is filled by foreman hosts (including host
groups and since foreman 1.5 configuration groups). That leaves a
profiles module. I think ovirt_infra suits that, so option 1.

That said, I'm not against renaming ovirt_infra to profiles and adding a
roles module. Then in foreman you only select a single role.

Also, I disagree it's the main guideline to build one module per role.
If your task is to define all profiles, then it's still one task.

Another disadvantage of many modules is that many of the standard puppet
testing tools work per module. If you want to write tests for every
module, you end up with a lot of files. We can have a look at writing
custom scripts that perform all tests, but there's something to say
about using standard tools puppet module authors are used to. (See
garethr/puppet-module-skeleton[1] for some ideas of a standard module.)

[1]: http://www.craigdunn.org/2012/05/239/
[2]: https://github.com/garethr/puppet-module-skeleton