+1 Data in modules is absolutely necessary!
On Sat, May 31, 2014 at 10:18 AM, Daniele Sluijters < [email protected]> wrote: > > 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 > <https://groups.google.com/d/msgid/puppet-dev/579481e0-f2bd-4162-b846-6602824c3c4e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoW4WqCO7P5gOwwrE1SfVVVSQmHEpdsX9_W%3Da63Ebzas6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
