On Monday, October 15, 2012 6:59:45 PM UTC-5, Nick Fagerlund wrote: > > > > On Monday, October 15, 2012 1:45:12 PM UTC-7, jcbollinger wrote: >> >> >> Indeed, I have taken a second look, and a third, and maybe more. I love >> the hiera integration with parametrized classes. It was a fabulous idea, >> as it makes it reasonable and safe to use existing parametrized classes >> (provided you use only 'include' or 'require' to declare them). >> >> Even with that, however, parametrized classes offer very little of value >> over non-parametrized analogs that implement the same hiera-based external >> data access. One could argue, perhaps, that there is a documentary >> advantage in parametrization, but I think that's poor justification for >> introducing functional (so to speak) elements to any class. That's what >> comments are for. >> > > But parameters expose that info to more than humans -- for example, you > can use the resource_type REST endpoint today to get a list of all classes > and their parameters and defaults. Not a lot is using that today, but I > expect more and more things to start doing auto-discovery of parameters, > since it's a really machine-friendly way to find out what a class "wants." >
That's an interesting angle of which I was not aware. I'm not sure I see a use case beyond automatic documentation generation, however, and there are alternative approaches that could serve that particular purpose. Do you envision other specific uses? Also, have you considered that any explicit hiera lookups in the class body also represent machine-discoverable things that a class "wants"? So long as there is no plan to deprecate the hiera functions, any approach to identifying classes' data dependencies that does not account for explicit lookups is incomplete. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/u5u9iR5s_8MJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
