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}
-
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
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}
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 =
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}
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
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).
