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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
