On Friday, May 30, 2014 8:48:18 AM UTC-5, Brian Mathis wrote: > > It sounds like you need to read through these: > http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/ > http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/ > > I don't see why you'd want to remove parameters from classes. They are > pretty critical to having a flexible infrastructure. > >
No, as a matter of fact not. What brings infrastructure flexibility in this area is relying on well-documented external data. Automated data binding makes it easy to conflate class parameterization with data externalization, but they are not at all the same thing, as anyone who used(-es) parameterized classes in Puppet 2 can attest. Obtaining data via explicit hiera*() calls for documented keys serves exactly the same data externalization aims as does automated class parameter binding. Class parameterization does bring some limited advantages to modules, in that modules featuring parameterized classes lend themselves to an additional mode of use (class parameters declared in manifests via resource-like class declarations), but that yields module flexibility toward its users, not flexibility of the managed infrastructure. I tend to discount that advantage, however, as it is usually poor practice to use resource-like class declarations even when your classes are parameterized (see, for example, PL's best-practices recommendation in the language reference <http://docs.puppetlabs.com/puppet/3/reference/lang_classes.html#include-like-vs-resource-like> ). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55260812-2a0e-486d-9df8-d6de98ec2262%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
