On Friday, June 22, 2012 7:02:33 PM UTC-4, Peter wrote: > > Hi Joh, > > On Wednesday, 20 June 2012 03:18:46 UTC+10, jcbollinger wrote: >> >> >> I confess that I don't follow what you are suggesting. Hiera already >> supports module developers providing data, and module users overlaying >> their own on top, in the order of their choice. What more would your >> suggestion provide in that area? And why do module developers need to >> configure specific locations for (the root of) their data on the >> filesystem? That should be under the control of module users (== the >> administrators of the master). What am I missing? >> >> > 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. >
I like where this idea is going. You would like a backend, hiera-puppet for now, to be able to lookup "default" data from the current module directory during parse time. Let's open a ticket (feature request) for this and workout the details. -- 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/-/Ib1O42g43JYJ. 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.
