I love hiera, but this is my biggest problem with it. There is no
scoping of the hiera name space. I am personally using the naming
convention "<module>_<class>_<variablename>, but it would be great if
hiera took care of that for me magically. A little birdy told me that
they are working on it, so here's hoping...
- Chad
On Fri, Mar 30, 2012 at 10:23 AM, Pablo Fernandez
<pablo.fernan...@cscs.ch> wrote:
> Well... that's why you have scopes, right? So that you don't need to know
> all variables in your tree, just the local ($var) and globals ($::var). At
> least it's how I understood it.
>
> In any case, the problem is not the variable name (I used other local
> variable names, and same problem happens). The problem is that
> hiera('netmask') is picking up a fact, when I believe it shouldn't.
>
> Thanks!
> Pablo
>
>
> On 03/30/2012 04:06 PM, Brian Gallew wrote:
>
> I would imagine this has to do with the whole, "you can't override
> variables" thing that comes with a declarative language. Truly, if you want
> do to this you need to just change the variable names so they won't conflict
> with the facter values. This is the primary reason (IMO) that example42 use
> my_ to prefix just about every variable they use.
>
> On Fri, Mar 30, 2012 at 7:02 AM, Pablo Fernandez <pablo.fernan...@cscs.ch>
> wrote:
>>
>> I have trying to dig more into this, and I found out the problem is not
>> the scope of the variable, but hiera!
>>
>> So, it seems like hiera('netmask') is actually looking into the node's
>> facts! Is this the expected behavior?
>>
>> This is my hiera.yaml:
>> :backends:
>> - puppet
>>
>> :hierarchy:
>> - %{hostname}
>> - %{environment}
>> - group_%{group0}
>> - group_%{group1}
>> - group_%{group2}
>> - group_%{group3}
>> - group_%{group4}
>> - group_%{group5}
>> - group_%{group6}
>> - group_%{group7}
>> - group_%{group8}
>> - group_%{group9}
>>
>> :puppet:
>> :datasource: data
>>
>> Most of those classes don't even exist. And data::myhost certainly
>> doesn't.
>>
>> And the place it should be looking into the right variable is:
>> class data::group_all {
>> $netmask = "255.255.252.0"
>> }
>>
>> (in this case, $group1='all')
>>
>> I have tried, for the sake of testing, to change the variable to something
>> different (and the hiera lookup) and it does the right thing, so I am quite
>> sure it's actually conflicting with the "netmask" fact.
>>
>> Any ideas?
>>
>> Thanks!
>> Pablo
>>
>>
>> On 03/30/2012 11:59 AM, Pablo Fernandez wrote:
>>>
>>> Hi,
>>>
>>> I have just found something very weird. I define this:
>>>
>>> define networking::basic_interface ($ip, $netmask = hiera('netmask'),
>>> $gateway = hiera('gateway')) {
>>> file { "/etc/sysconfig/network-scripts/ifcfg-${name}" :
>>> content =>
>>> "DEVICE=${name}\nIPADDR=${ip}\nNETMASK=${netmask}\nGATEWAY=${gateway}\nONBOOT=yes\n",
>>> mode => '0644', owner => 'root', group => 'root',
>>> }
>>> }
>>>
>>> And create the resource doing:
>>> networking::basic_interface { "eth0:0": ip => '1.2.3.4' }
>>>
>>> So, the variables $netmask and $gateway should pick up their default
>>> values, that are taken from Hiera. But then, when I apply the manifests in
>>> the node, the value picked up is the one from Facter.
>>>
>>> To summarize: the content of the file takes ${netmask} which is a
>>> parameter of the define, but it turns out that the fact $::netmask has
>>> preference over it. How is it possible?
>>>
>>> Thanks!
>>> Pablo
>>>
>>
>> --
>> 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.
>>
>
> --
> 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.
>
>
> --
> 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.
--
Chad M. Huneycutt
--
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.
