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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/b6ccac8b-c15e-4741-a4b3-2cfa2cef970d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
