+1 Data in modules is absolutely necessary!
On Sat, May 31, 2014 at 10:18 AM, Daniele Sluijters < daniele.sluijt...@gmail.com> 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 puppet-dev+unsubscr...@googlegroups.com. > 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 tvaug...@onyxpoint.com -- 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 puppet-dev+unsubscr...@googlegroups.com. 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.
