On Tuesday, May 20, 2014 6:25:10 PM UTC+2, John Bollinger wrote: > > > > On Monday, May 19, 2014 11:42:57 AM UTC-5, Alessandro Franceschi wrote: >> >> >> The hierarchy of such a tp module has to be module specific and should >> not depend on how data is managed in users’ hiera.yaml. >> Default data for the managed applications should be placed in the same tp >> module and be based on a module specific hierarchy, it would contain >> references to osfamily/operatingsystem/etc facts that can’t be forced into >> the users’ own local hierarchies (besides that fact that imho in a sane >> /etc/puppet/hiera.yaml file there should not be references to OS related >> facts) . >> > > > Ok, but you're throwing a curve there. Your original suggestion / request > had none of those constraints. Would those concerns be adequately > addressed if R.I.'s data in modules were in the core product? > Alternatively, would it be acceptable for the 'tp' module to depend on a > module providing that feature? Or to provide that or something equivalent > itself? >
The constraints were somehow implicit in how I described the expected behaviour, I suppose. The module can have other dependences, if needed. I've started to do something around it, still far from working as expected, it's more a readme driven development, and I'm evaluation alternative approaches both for the defines and the parameters to use and how to structure the internal data. Some experiments are online https://github.com/example42/puppet-tp feel free to comment / suggest, as everything there is under discussion. I'd like to use internally hiera in some way, but I don't think it's still possible, so I'm going to use a custom "tp_lookup" function that is going to mimics its basic functionality. 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) > > 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. thanks, al > > > 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/18fdb742-3b59-429d-ba37-d785f4f44ae6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
