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.
