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 [email protected]. 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.
