Hi Gary,
I know what you mean, and agree for modules destined to be released to the wild. unfortunately, we have a diverse enough environment that even the defaults occasionally need to be overridden; hence the hierification. (I've got all that logic wrapped into a case statement based on if the global parameter hiera_enabled is true or false, with sane-ish defaults when hiera isn't enabled) On Dec 7, 2012, at 12:35 PM, Gary Larizza <g...@puppetlabs.com> wrote: > I tend to take the stance that things in modules that AREN'T specific to your > company (i.e. things that could help others - like names of packages on other > OS platforms, config file paths, etc) should be kept in the Module and not > locked up in Hiera data (that way, both people using and NOT using Hiera can > benefit from them). I HAVE in the past put that data in Hiera, but have also > find that it can bloat the hierarchy. I'm curious as to what others think, > as this is my opinion and not necessarily 'best practice'. > ________________________________ This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
