On Tuesday, 29 January 2013 10:07:29 UTC-5, Ti Leggett wrote: > > I'm not sure I fully agree with this from a design standpoint. In > object-oriented programming, one of the design principles is that variables > relating to the object are encapsulated within the object and exposed or > not depending on how they should be accessed. IMHO, it also makes it more > obfuscated when you're accessing say the SSL CA cert path variable and > that's in some 'common' module that everything has to include. Granted it > makes it easier on the module developer - just always in include the common > module and your variables should be there - but it also makes it less > explicit.
How would you handle variables that wouldn't otherwise be tied to a module? An example I ran into when I was doing our first deployment was the path to various shells. They vary from OS to OS, but rarely (if ever) need a whole module to manage them. The paths get referenced in many places, such as when adding users or installing scripts (erb used in the bangpath). I've found it useful to have things like $::site::params::bash and $::site::params:tcsh for shells, and other site-wide variables for other things. It means I only need to put the case logic to figure out the path based on the OS in one place, and not have it scattered around several modules that all need to figure out the same thing. -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
