Thanks for the great replies Nigel. As a person currently rolling out Puppet into production I'm stricken with doubt about how to best represent variables in a module. It would seem to me that I need to:
1. set default values in params.pp (based on facts, yadda yadda) 2. allow those values to be overridden by global namespace variables (for enc support) 3. further allow parametrized class declarations to take precedence over 1 and 2 Can you point me to a module that does this? Alternatively, can you make a recommendation for module best practices going forward. Thanks, Ryan Bowlby On Jan 16, 9:31 am, Nigel Kersten <ni...@puppetlabs.com> wrote: > On Mon, Jan 16, 2012 at 7:23 AM, Alessandro Franceschi <a...@lab42.it> wrote: > > > On Sunday, January 15, 2012 9:30:02 PM UTC+1, Nigel Kersten wrote: > > >> So here's the rough idea we have in place. > > > Let me contextualize: What you suggest here is what may be introduced in > > 2.8 , when Hiera will be integrated into Puppet? > > Yes, but "Telly", not "2.8". > > We may use Telly to fully adopt Semantic Versioning (http://semver.org) > and take this opportunity to reset to "3.0.0" instead of "2.8". > > > > > > > > > > > > >> Parameterized class lookups are automatically consulted in a Hiera > >> backend. > > >> The lookup order would be as follows: > > >> 1. directly supplied value in the declaration of the class: > >> class { "foo": param => "value" } > > >> 2. Hiera backend > > >> 3. Default value supplied in the definition of the class: > >> class foo ($param = "value") { ... } > > >> This would happen automatically, without requiring the use of a hiera() > >> like function in the class definition. > > > +1 > > I like the fact that this is transparent... if you have an Hiera backend > > then it's used, if not (or if you use an older Puppet version), normal > > behavior is followed. > > Yep. > > > > > > > > > > > > > It's clear that we need to have a way for module authors to specify values > >> in the definition of the class. > > >> Is this satisfied well by having the values in the manifests themselves > >> as in (3) above? > > > Well a simple class foo ($param = "value") { ... } might not be enough, > > some logic (for example a different value for different operating systems) > > to give defaults values might be needed (back to params.pp ...) > > >> Or should we be encouraging authors to put a Hiera-style backend inside > >> their modules and have that be consulted for default values? > > > For me is saner to leave to puppet dsl the management of the values to > > attribute to these internal variables. > > It's how we always have done it and, for me, it works. > > But this is really because there has been no other option right? It's never > really been easy for module authors to ship default data values inside > modules, but not in manifests. > > I agree it works, but I'd like us to think about whether we can improve it. > > > > >> I'm not particularly fond of the work we're making people do around > >> polluting the global namespace with class-specific data. > >> That's something I think we should probably remove entirely, but open to > >> suggestions. > > > -1 if I understood well > > If you mean that you would remove the possibility to define top scope > > variables with custom names (ie things like ::monitor = true but also > > ::monitor_openssh = true) please let me know when and how this could happen. > > No no no. > > I more meant that we've had a whole lot of clustered behavior that has > meant we've forced people to use global namespace variables in say ENCs to > pass down to modules. > > Users and authors shouldn't *have* to do that, and I'd like to make sure > we're giving people better options than always having to put everything in > top scope. > > > As a user I'm not so fond of radical changes in the Puppet code that make > > unusable manifests made for earlier Puppet versions (hint: dynamic > > variables scoping no more possible in 2.8: I understand that they were a > > source of various problems, but that was just for users misuse due > > eventually to not clear enough directives/documentation/best practices). > > I understand that this is done for a "better future" and that > > retrocompatibility should not be a dogma, but... well... when I write some > > Puppet code I hope it's going to work for some years... > > I'd argue that the dynamic variable scoping resulted in quite fundamental > problems, but yes, there's totally a balancing act here between progress > and compatibility. -- 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.
