On Sunday, January 15, 2012 9:30:02 PM UTC+1, Nigel Kersten wrote:
>
>
>
> On Sun, Jan 15, 2012 at 12:42 AM, Alessandro Franceschi <a...@lab42.it>wrote:
>
>>
>> So, to reply to your question, Nigel, something like a hiera backend or a
>> Puppet function that does what is written before in any Puppet setup would
>> be what I need.
>>
>> The ideal, maybe, would be a simple function that does the above and then
>> if Hiera is in place, uses Hiera without requiring it: I really would like
>> to reach a scenario where a person picks a single module and eventually the
>> dependent modules (stdlib and so on), and can use it on his Puppetmaster
>> without the need to introduce Hiera on it, if it's not already there.
>> This, at least, until most of the people will have a PuppetMaster with
>> integrated Hiera ... till that moment I would like to have modules usable
>> in the widest range of Puppet setups possible.
>>
>>
> 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?
>
> 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.
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.
> 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.
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...
my2c
al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/2w8gjokGqxQJ.
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.
