hello,
Till now hiera-puppet was the only way I know that allowed hiera data to
be loaded from inside a module.
The problem with this was that it was still subject to the site specific
hierarchy which means a module author had a pretty hard time to store
his data in a proper way in his module thus perpetuating the use of the
params classes pattern.
Now that Puppet 3 is out and it's gem extensible I can finally try some
ideas I had but put off implementing because it was too hard to install
and distribute these extensions.
I propose extending the module layout with a data/ directory that can go
into each module and in this data directory would live a hiera config
file (optionally) and module specific data:
your_module
├── data
│ ├── hiera.json
│ └── osfamily
│ ├── Debian.json
│ └── RedHat.json
└── manifests
└── init.pp
Here the data/hiera.json is optional and specifies a hierarchy that the
module author chooses and is unique to the specific backend.
The default contents would be this is the file is absent:
{"hierarchy": ["osfamily/%{osfamily}", "common"]}
But a module author can pick anything there, should even be able to rely
on facts that is shipped with the module in its lib dir since that'll
get pluginsynced out before compile time:
Now given the data files for Redhat:
{"apache::package" : "httpd"}
...and Debian:
{"apache::package" : "apache2"}
And your main hiera site config being something like:
:backends: - json
- module_json
You should be able to just write module code like this:
class apache($package="apache") {
package{$package: ensure => present}
}
If no data is specified in the site hiera backends then this will use
the in-module hierarchy and data and just do the right thing on RedHat
and Debian systems but as always the site can still override the data
using hard coding, site specific data, ENCs etc.
So the important thing here is the module author has control over the
hierarchy that gets used when the data in his module gets loaded. The
site can has its own hierarchy policy but this backend will only use
the hierarchy that is recorded in the module by its author.
If you want to play with this idea on your Puppet 3 install just do 'gem
install hiera-module-json'
So I am looking for feedback from the community on this pattern, will it
solve the problem of author-supplied module data better than we have
today? I've heard this problem brought up quite a lot so keen to hear
feedback.
I'd imagine eventually a backend like this might be a hard-coded backend
shipped with puppet and always there as the lowest priority backend
below any that the site might specify in their site wide hiera config so
everyone can rely on this being there and with the new lookup helpers
this should also be backward compatible - old Puppets or ones who
specifically disable the hiera indirector will just not have data and
will need to supply it some other way.
---
R.I.Pienaar
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
