Use an external node classifier to map nodes to classes

[fhd]

Background

Right now, nodes are defined in the manifests imported by site.pp. We should use an external node classifier to not expose our exact infrastructure, and provide a stub ENC that configures nodes for all classes.

What to change

Use an external node classifier to map nodes to classes. The biggest deal here is probably to make the monitoring configuration generic.

[poz2k4444]

I've been reading about this one, and maybe it could be a better idea to use Hiera instead of ENC, you could check the pros and cons here:

​http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code

[trev]

I think the main issue with Hiera was: ruby-hiera-puppet package isn't available for Ubuntu 12.04. fhd, do you remember more than me here?

[fhd]

No, I never looked into Hiera personally. Looking through this a bit, I think I'm still leaning towards an ENC. Simpler, highly flexible and it's built-in (Hiera not yet). The cons listed in that comparison seem a bit dubious to me.

What would the actual benefits of using Hiera be for us?

[trev]

The main benefit would be having actual data files that we can access from the Puppet manifests, without the additional complexity of a script. However, I tried to install Hiera on Ubuntu 12.04 and this seems complicated enough that it isn't worth doing. After all, we can just use the same data files but have our ENC script read them.

For reference: Hiera is built into Puppet 3 but Ubuntu 12.04 uses Puppet 2.7. There is no install package so you need to install the Ruby gem. And that gem is installed to a location where Puppet doesn't pick it up. In theory, symlinking from /etc/puppet/modules to the gem install directory should do - but that didn't work for me, I still couldn't use the hiera() function. There is no obvious way to debug this issue and no helpful documentation.

[matze]

Can you please create a pull request for that?

I know @trev suggested in #IRC that we do not need one in general, but it's way more comfortable for reviewing the current state, especially since recent history and any intended changes are easily accessible (AND linked in the "Review URLs" section above), and because it allows to easily place and review comments as well.
Furthermore, since GitHub will auto-update any pull request when new commits are introduced in either source or target branch, this is probably the easiest way to go.

[trev]

FYI: The current state is visible under ​https://github.com/aalvz/infrastructure/tree/enc. The problem is, at the moment there are many unnecessary changes that will make the pull request unnecessary hard to review. In particular, the subrepositories have been checked in. That's why I suggested cleaning up first and only create a pull request later. But it probably makes sense to do this and to clean up whatever prevents useful reviews there.

[matze]

A general status update for reference and documentation: We've decided to follow the Hiera approach. @aalvz, @poz2k4444 and @matze are currently working on addressing the last issues from the code-review (see the linked review-URLs).

[matze]

​https://hg.adblockplus.org/infrastructure/rev/7b541c38184e