On Fri, Jun 22, 2012 at 7:02 PM, Peter <pe...@ifoley.id.au> wrote: > > > Thanks for taking the time to reply. > > Yes hiera provides support for module developers ... however I would argue > that it is limited for example, the hiera-puppet plugin is *hard-coded* to > only look for values in the module manifest directory for a file called > data.pp. > > This does allow for a very low threshold for module developers to start > implementing hiera in their modules (rename their existing params.pp files). > > I believe by extending the hiera-puppet plugin for module developers to > follow a similar convention as hiera for module users would make certain > things easier for module developers. > > By providing the ability to signal the hiera-puppet plugin (using a > module-hiera.yaml file (for lack of a better name)) a module developer > could reduce complexity and use the DRY principle to setup sane defaults > (either in a defaults.pp or in a defaults.yaml file) and than use layer on > top specific settings for Operating systems or even Hardware Types (as > examples). > > Sorry I don't have time right now to provide something in depth but a > brief example would be setting up ISCSI, the module I currently have has a > complex params.pp file for detecting particular setups. > > As a module developer I am interested in setting up a hierarchy such that > from most specific to least specific: > * Hardware_platform > * Operating System > * Defaults > > By defining this in the module-hiera.yaml file it makes it very easy for > me to signal to the module user what settings override which. > > I am not suggesting taking any control from module users, and to be > explicit user settings (if set) would override the module variable. > > Hopefully I have done a better job of explaining what I am thinking. > > Thanks, > > Peter. >
If I understand your idea correctly then I too would like to see this. We would be able to use a hierarchy within the module (when sharing on the forge) to provide various defaults without having to do a bunch of selectors on $operatingsystem etc and make it easier for someone to start providing overrides from their own hiera data. Right now to provide defaults that differ for an operating system you would have to do a bunch of logic in params.pp that the person would want to strip out and replace with a call to hiera anyway. By allowing us to create params.pp as a series of hiera calls in the first place it'll reduce the amount of modifications (hopefully to zero) when taking a module off the forge. -- 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.
