our custom facts fail, when they could instead just use facter! #198
Assignees
Comments
igalic
changed the title
|
fixed by this (in theory): #200 |
|
i'll update my production servers with this, and see how they blow up |
|
they don't. however, it doesn't work via |
|
I'm not sure if i got what happens. If i got this right:
|
|
could this be an ordering issue? |
|
don't think so. I don't think I understand what the issue is, that's why i'm asknig what the output of the commands is. |
|
|
now that is interesting |
|
can you post the output of |
{
domain => "esat",
fqdn => "app02.esat",
hostname => "app02",
interfaces => {
eth0 => {
bindings6 => [
{
address => "2a01:4f8:211:9d6::36",
netmask => "ffff:ffff:ffff:ffff::",
network => "2a01:4f8:211:9d6::"
},
{
address => "fe80::5054:ff:fe45:9aec",
netmask => "ffff:ffff:ffff:ffff::",
network => "fe80::"
}
],
ip6 => "2a01:4f8:211:9d6::36",
mac => "52:54:00:45:9a:ec",
mtu => 1500,
netmask6 => "ffff:ffff:ffff:ffff::",
network6 => "2a01:4f8:211:9d6::"
},
lo => {
bindings => [
{
address => "127.0.0.1",
netmask => "255.0.0.0",
network => "127.0.0.0"
}
],
bindings6 => [
{
address => "::1",
netmask => "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
network => "::1"
}
],
ip => "127.0.0.1",
ip6 => "::1",
mtu => 65536,
netmask => "255.0.0.0",
netmask6 => "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
network => "127.0.0.0",
network6 => "::1"
}
},
ip6 => "2a01:4f8:211:9d6::36",
mac => "52:54:00:45:9a:ec",
mtu => 1500,
netmask6 => "ffff:ffff:ffff:ffff::",
network6 => "2a01:4f8:211:9d6::",
primary => "eth0"
} |
|
Huh, I don't get it. The hash looks the same for me too. Is it because of the way it is accessed? |
|
what version of ruby are you using? |
|
updated |
|
If you clone puppet-network in the system it is failing and run inside the puppet network folder |
|
|
so not an issue with the code per se, but a loading issue. I'm not sure if i can help debug that but maybe something wrong with the puppet-network version installed/loaded in the master/agent? |
|
Maybe running |
|
|
Huh this is why the old implementation failed:
Right so, it seems to me that it executes the code inside the network_primary_interface fact that calls facter to get the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
What are you seeing
What behaviour did you expect instead
We should defer to facter3, instead of trying to figure all of this out on our own.
The text was updated successfully, but these errors were encountered: