Issue #16856 has been updated by R.I. Pienaar.
I'd add here some points I mentioned to Ryan earlier. This is specifically
what I found why placing this kind of data in data files beats putting it in a
params.pp full of case statements.
Consider:
<pre>
case $::operatingsystem {
"debian": { $pkg = "apache2" }
"redhat": { $pkg = "httpd" }
}
</pre>
versus just having a RedHat.json and a Debian.json.
When the module author wants to add another Operating System or update an
existing OS he'd only change the data files, this is significant because:
* Editing the data is less error prone than the case statements simply because
there is a lot less syntax and stuff to consider
* The risk of adding a new OS when it is only data is completely contained -
suse.yaml will only be consulted on suse machines. There's no chance that
redhat/debian/etc machines will be affected by the change to add a new OS
support into the module. So even if a error is made in a new yaml file the
error is contained to that specific OS only - you could not break the entire
module without making mistakes in every data file for every OS.
* I found while deploying modules configurable by data and not code in large
environments with complex change control requirements that changes to
configuration data required less change control than changes to case
statements. In some cases we even got agreement to not require any code review
on data changes. In any event the change review process is easier if all you
have to consider is data changes and no logic changes.
* Following on from the last point if a module is hosted somewhere like GitHub
it's easier to contribute new OS support and easier to review the addition
So while on a superficial basis you can get far with the params.pp pattern
exploring and supporting ways to fully separate data and code has significant
advances to module authors wrt how their modules are used and the life cycles
of those modules.
Doing this in a way that is consistant with the design of the already present
hiera enhances the overall solution and get us nearer to the point of having a
single way to handle data thats adopted by a majority of the community and I
believe ultimately to a better forge eco system.
----------------------------------------
Feature #16856: puppet should support data in modules
https://projects.puppetlabs.com/issues/16856#change-79153
Author: R.I. Pienaar
Status: Needs More Information
Priority: Normal
Assignee: R.I. Pienaar
Category:
Target version:
Affected Puppet version:
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/1217
At present there is a way to store data in modules using the puppet backend for
hiera but it is optional and kind of broken. The site hierarchy impacts how
the puppet backend behaves which makes it impossible for module authors to
supply data in their modules they can rely on
I propose a new hiera backend that loads a hierarchy of data from the 'data'
directory in the module, this module must always be present in a puppet
install. This ability is key to the ability to create configurable forge
modules that do not have hard coded values thanks to the puppet 3 hiera
integration
reference the users list thread
https://groups.google.com/d/topic/puppet-users/pvqzeyHkrY4/discussion
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
