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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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.fernandez@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+unsubscribe@** > googlegroups.com <puppet-users%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/puppet-users?hl=en<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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.fernandez@cscs.ch <mailto:pablo.fernandez@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
> <mailto:puppet-users@googlegroups.com>.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com
> <mailto:puppet-users%2Bunsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Mar 30, 9: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.You understand it the same way I do. Besides, Puppet will normally issue a parse error if you attempt to re-declare a variable, so the fact that you do not get one suggests that Puppet is indeed recognizing your declaration as a local variable. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.fernandez@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.fernandez@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mar 30, 9: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}That long list of numbered groups looks pretty kludgey, but I don''t think that''s the root cause of your problem.> :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'')Only in a loose sense. It may be that $::group1 = ''all'', but the local variable $group1 is not defined in your example context. From where the $group1 variable is resolved could be a key question. Is it a fact or a global variable? Those ought to work. If it''s declared in the node declaration, however, then that might be your problem: I''m not sure whether those would work in Puppet 2.7 (or earlier). They almost surely will not work in Telly, so you should avoid building solutions around them. Also, are you certain that data::group_all is the first existing class in hierarchy order? Does the node''s $group0 not correspond to an existing data class? What about data::%{environment}? Is there a "data::group_" class that might be checked when one of the $groupN variables is undeclared or has an empty value?> 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?My guess is that there is an existing class higher in the hierarchy than data::group_all ends up being, and although that class doesn''t declare a ''netmask'' variable itself, lookup relative to that class pulls in $::netmask (because it is in-scope there). John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 30.3.2012 16:02, Pablo Fernandez wrote:> 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'')Does hiera really look up in data::group_all ? If you enable debug for puppetmasterd it should print out the files and classes hiera looks at. $ puppetmasterd --no-daemonize --debug -- Kind Regards, Markus Falb
Hi again,
Ok, this one is getting more interesting. I have tried the --debug
option, and I see something very strange. It is going to be a bit long
(sorry, I was asked for more details). Let me first clarify what I do
with the hierarchy:
:hierarchy:
- %{hostname}
- group_%{group0}
- group_%{group1}
- group_%{group2}
...
- group_%{group9}
Then, from site.pp, the first thing I do is import groups.pp that
defines all the groups there are, searches the current hostname in all
the groups, and populates the $group0, $group1, etc. accordingly, this
way. If you believe the above sentence, you can skip it to the next
paragraph:
# Available groups (there is also preproduction, but they are the same)
$production_groups =
[''lrms'',''cream'',''wn'']
# Groups
$group_wn = range("wn01","wn46")
$group_cream = ["cream01","cream02"]
$group_lrms = ["lrms01", "lrms02"]
[...]
# Combine and flatten all production groups into new "automatic"
groups:
# production, preprod, and all:
$group_production = split (inline_template(''<%= array=[];
production_groups.each { |x| array << eval("group_#{x}")};
array.flatten.uniq.join(",") %>''), ",")
# $group_preprod does the same, but with preprod
$group_all = flatten ([$group_production, $group_preprod]) # All machines
$allgroups = flatten ([$production_groups,
$preprod_groups,''production'',''preprod'',''all''])
# And now we search for the current machine, to see which groups does it
belong to:
$groups_string = inline_template(''<%= array=[]; allgroups.each{ |x|
array << x if eval("group_#{x}").include?(hostname) };
array.join(",") %>'')
$groups = split($groups_string, ",")
# And populates the $group0, $group1..$group9
if ($groups[0]) { $group0 = $groups[0] } else {$group0 = ""}
if ($groups[1]) { $group1 = $groups[1] } else {$group1 = ""} [...]
if ($groups[9]) { $group9 = $groups[9] } else {$group9 = ""}
In my example, I do a notify $groups_string and my node (ppwn01) belongs
to groups "ppwn,preprod,all"
That means Hiera() will look for data::ppwn01, data::ppwn,
data::preprod, data::all. And in fact it does, if we take a look at a
sample lookup in the debug output:
debug: hiera(): Looking up postfix_relay_host in Puppet backend
debug: hiera(): Looking for data in data::ppwn01
debug: hiera(): Looking for data in data::group_ppwn
debug: hiera(): Looking for data in data::group_preprod
debug: hiera(): Looking for data in data::group_all
In other examples, it stops as soon as it finds the right value, and in
the cases I do a hiera_array() it goes to all the empty groups:
debug: hiera(): Looking up root_authorized_keys in Puppet backend
debug: hiera(): Looking for data in data::ppwn01
debug: hiera(): Looking for data in data::group_ppwn
debug: hiera(): Looking for data in data::group_preprod
debug: hiera(): Looking for data in data::group_all
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in data::group_
debug: hiera(): Looking for data in ssh::root_authorized_keys::data
debug: hiera(): Looking for data in ssh::data
After the _all they don''t exist, but that''s ok with Hiera. So
far so
good. This behavior repeats all the time I use hiera() or hiera_array(),
as it should, but when I search for hiera(''netmask''), I get
the following:
debug: hiera(): Looking up netmask in Puppet backend
warning: Dynamic lookup of $hostname is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group0 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group1 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group2 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group3 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group4 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group5 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group6 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group7 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group8 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
warning: Dynamic lookup of $group9 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
debug: hiera(): Looking for data in data::ppwn01
debug: hiera(): Looking for data in data::group_ppwn
warning: Dynamic lookup of $netmask is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g.,
$classname::variable) or parameterized classes.
Something triggers those complains, that didn''t show up before. If I
change hiera(''netmask'') by
hiera(''public_netmask'') there are no
complains, and it all happens as it should. I could understand complains
about setting $netmask = ''blabla'' in class data::all, but the
other
complains?
Just to clarify, $netmask is defined ONLY in data::group_all.
The interesting part seems to be here: the lookup stops in
data::group_ppwn. It is defined this way:
class data::group_wn {
# This is needed to connect freely from/to the CE
$sshd_HostbasedAuthentication = ''yes''
$sshd_IgnoreUserKnownHosts = ''yes''
}
class data::group_ppwn inherits data::group_wn {
# We can override any value here
}
I do it this way, because I have the production group (group_wn) and the
pre-production group (group_ppwn), and I want them to be cloned, but I
want to be able to override values in the pre-production group (and
avoid repeating the same values in a completely separated group schema).
I have tried doing that, and the overrides work quite nicely, but...
could it be that the Facts are also inherited? It really seems like,
otherwise why would Hiera stop looking there?
(I have tried include instead inherits, and the variables are not
accesible within the same scope, so hiera does not find them)
I hope I gave a better insight on where does the problem exist. I can
really workaround this by avoid using fact names in hiera lookups, but
understanding what is going on can avoid other problems in the future.
Thanks a lot for your time!
Pablo
On 04/02/2012 06:54 PM, Markus Falb wrote:> On 30.3.2012 16:02, Pablo Fernandez wrote:
>
>> 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'')
> Does hiera really look up in data::group_all ?
> If you enable debug for puppetmasterd it should print out the files and
> classes hiera looks at.
>
> $ puppetmasterd --no-daemonize --debug
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Apr 3, 3:17 am, Pablo Fernandez <pablo.fernan...@cscs.ch> wrote:> class data::group_wn { > # This is needed to connect freely from/to the CE > $sshd_HostbasedAuthentication = ''yes'' > $sshd_IgnoreUserKnownHosts = ''yes'' > > } > > class data::group_ppwn inherits data::group_wn { > # We can override any value here > > } > > I do it this way, because I have the production group (group_wn) and the > pre-production group (group_ppwn), and I want them to be cloned, but I > want to be able to override values in the pre-production group (and > avoid repeating the same values in a completely separated group schema). > I have tried doing that, and the overrides work quite nicely, but... > could it be that the Facts are also inherited? It really seems like, > otherwise why would Hiera stop looking there?I''m still thinking about this. The messages about dynamic lookup of $netmask are pointing toward the theory I proposed before: variable lookup in the context of an existing class that does not itself define a local $netmask variable is pulling in $::netmask (or maybe a containing class''s or superclass''s $foo::netmask). If it''s $::netmask getting pulled in, however, then I don''t understand why lookup stops in the *second* class instead of in the first. Do note, however, that you should be very careful with the variable "override" idea. In particular, you need to understand that Puppet doesn''t have any such concept: what you are actually doing is _hiding_ variables declared in outer scopes. The difference is that hiding a variable is scope-dependent. Both variables still exist, and which value you get in any expression depends on that expression''s context. I would recommend avoiding such usage. In fact, I would typically recommend Hiera as an alternative -- use the data hierarchy instead of a class hierarchy to do this for you . John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.