> So, if you're willing to depend on other modules, then I think ripienaar/module-data <https://forge.puppetlabs.com/ripienaar/module_data> combined with explicit lookups can do a lot of what you're after.
Honestly, that should just be part of Puppet core. It's such an incredibly useful feature and would go a long way to help people out in such scenario's. It might not be the utopia Alessandro is shooting for but it's certainly a good compromise. On Tuesday, 27 May 2014 17:41:11 UTC+2, John Bollinger wrote: > > > > On Monday, May 26, 2014 11:01:59 AM UTC-5, Alessandro Franceschi wrote: >> >> >> >> On Tuesday, May 20, 2014 6:25:10 PM UTC+2, John Bollinger wrote: >> > > [Al:] > > >> If you have any suggestion on how to use directly Hiera that would be >> welcomed, as usual. >> >> >>> >>> >>> > Thanks anyway for the attempt, hopefully now is clearer why I can’t do >>> this with existing functionalities. >>> >>> >>> Your requirements are clearer, yes. What's not quite clear yet is >>> whether you want to avoid your data binding falling back to general data >>> when resource parameters are not found in module-specific data. If you do >>> want to avoid that then I think you're right that existing functionalities >>> won't do what you want, but then I'm certain that you were wrong earlier >>> about what you want being achievable by a simple modification. >>> >> >> Well, if data binding for defines is not a possibile approach, the module >> will have its internal default values for parameters and accept (of >> course) users' overrides. >> I still have to figure out how to merge user provided data with internal >> default data ( I think it make sense to expose a parameter that let the >> user define the merge behaviour) >> >> > > > To what extent would you still have this problem if you could use hiera > directly? I'm thinking that the issue there might be only that there are > parameters that you wish to actively prevent the user from overriding. If > that's the only thing, then would you be willing to give up active > enforcement for documentation (i.e. telling users "don't do that")? > > > >> >>> On the other hand, I think you could put a custom function into module >>> 'tp' that would read data from (only) a module-specific data source, along >>> lines similar to hiera. If you used such a function instead of hiera(), >>> then could a solution along the lines I described work for you? >>> >> >> Yep, the tp_lookup function mentioned earlier is expected to do what I'd >> have preferred to do via Hiera data bindings (on defined params) + module >> in data. >> > > > So, if you're willing to depend on other modules, then I think > ripienaar/module-data <https://forge.puppetlabs.com/ripienaar/module_data> > combined with explicit lookups can do a lot of what you're after. It gives > you an always-on (doesn't depend on the user modifying hiera.yaml), > in-module data source from which you can look up the needed data. For > defined types and current Puppet, that necessarily involves explicit > lookups, as we already discussed. > > If that combination leaves essential features unserved, then perhaps at > least R.I.'s module can give you ideas for how to build your own -- maybe > just the same thing but defaulting to highest priority. > > > John > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/579481e0-f2bd-4162-b846-6602824c3c4e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
