I am looking forward to testing this out in my test lab, as this is
something I have been looking for for quite a while. (That, and a good
deployment mechanism, while waiting for Razor to mature.)
Thank you for putting this out for testing/reflection.
--
Patrick Roberts
On Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote:
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/J0XkwA_MAQUJ.
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.
