network_* facts don't work on OpenVZ

[joschi]

If OpenVZ (or Virtuozzo) is being used for virtualization the facts network_nexthop_ip, network_primary_interface, and network_primary_ip do not work because the default route is set to a (virtual) ethernet device instead of an IP address.

dev:~# facter virtual
openvz
dev:~# facter interfaces
lo,venet0,venet0_0
dev:~# /sbin/ip route show 0/0
default dev venet0  scope link 

This leads to warnings on every Puppet run:

dev:~# puppet agent --noop -t
Info: Retrieving plugin
Info: Loading facts in /etc/puppet/modules/network/lib/facter/network.rb
[...]
need at least destination address
Could not retrieve network_primary_ip: private method `split' called for nil:NilClass
need at least destination address
Could not retrieve network_primary_ip: private method `split' called for nil:NilClass
need at least destination address
Could not retrieve network_primary_ip: private method `split' called for nil:NilClass
need at least destination address
Could not retrieve network_primary_interface: private method `split' called for nil:NilClass
need at least destination address
Could not retrieve network_primary_interface: private method `split' called for nil:NilClass
need at least destination address
Could not retrieve network_primary_interface: private method `split' called for nil:NilClass
[...]

[wolfspyre]

Hi there!

Thanks for reporting this. So, it's failing because we're expecting to get an ipaddress out:
/sbin/ip route show 0/0
default via 192.168.56.2 dev eth1
instead of just the device...

Could you provide the output of /sbin/ip route show on an example node? I don't have an OpenVZ environment in which to test this.

[joschi]

Here's the output of ip route show and ip link show:

# ip route show
default dev venet0  scope link

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void

Maybe the relevant (?) Facter output is also helpful:

# facter|grep -E '^(ip|interface|net)'
interfaces => lo,venet0,venet0_0
ipaddress => 192.168.100.1
ipaddress_lo => 127.0.0.1
ipaddress_venet0 => 127.0.0.2
ipaddress_venet0_0 => 192.168.100.1
netmask => 255.255.255.255
netmask_lo => 255.0.0.0
netmask_venet0 => 255.255.255.255
netmask_venet0_0 => 255.255.255.255
network_lo => 127.0.0.0
network_venet0 => 127.0.0.2
network_venet0_0 => 192.168.100.1

[wolfspyre]

I'll see if I can't make this behave a little better. Thanks for the outputs. I'll let you know if I need anything further once I get a chance to sit down and look at this.

[wolfspyre]

Could you give me a full facter output (perfectly okay to synthesize anything that might be sensitive) from an OpenVZ node?

[wolfspyre]

Hi again,

to be certain, can you post the output of a few different OpenVZ network configurations?

ip route show 0/0
ip route show
ip link show

can you add multiple interfaces to an OpenVZ node? for example, a VM-only network, and an egress access network? could you provide the above outputs with that configuration, as well as stock?

[wolfspyre]

also what's the output of ip route get 8.8.8.8 in both situations?

[joschi]

Hi,
thanks for picking up this issue.

Here's the output of facter and the ip commands on a OpenVZ container with a single venet network device that you've requested:

# facter
architecture => amd64
domain => [REDACTED]
facterversion => 1.7.1
filesystems => ext2,ext3,ext4
fqdn => [REDACTED]
hardwareisa => unknown
hardwaremodel => x86_64
hostname => [REDACTED]
id => root
interfaces => lo,venet0,venet0_0
ipaddress => 192.168.100.147
ipaddress_lo => 127.0.0.1
ipaddress_venet0 => 127.0.0.2
ipaddress_venet0_0 => 192.168.100.147
is_virtual => true
kernel => Linux
kernelmajversion => 2.6
kernelrelease => 2.6.32-20-pve
kernelversion => 2.6.32
lsbdistcodename => wheezy
lsbdistdescription => Debian GNU/Linux 7.1 (wheezy)
lsbdistid => Debian
lsbdistrelease => 7.1
lsbmajdistrelease => 7
memoryfree => 1.67 GB
memoryfree_mb => 1714.10
memorysize => 2.00 GB
memorysize_mb => 2048.00
memorytotal => 2.00 GB
mtu_lo => 16436
mtu_venet0 => 1500
mtu_venet0_0 => 1500
netmask => 255.255.255.255
netmask_lo => 255.0.0.0
netmask_venet0 => 255.255.255.255
netmask_venet0_0 => 255.255.255.255
network_lo => 127.0.0.0
network_venet0 => 127.0.0.2
network_venet0_0 => 192.168.100.147
operatingsystem => Debian
operatingsystemmajrelease => 7
operatingsystemrelease => 7.1
osfamily => Debian
path => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/gems/1.8/bin
physicalprocessorcount => 0
processor0 => Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
processor1 => Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
processorcount => 2
ps => ps -ef
puppetversion => 3.2.2
rubysitedir => /usr/local/lib/site_ruby/1.9.1
rubyversion => 1.9.3
selinux => false
sshdsakey => [REDACTED]
sshfp_dsa => [REDACTED]
sshfp_rsa => [REDACTED]
sshrsakey => [REDACTED]
swapfree => 255.42 MB
swapfree_mb => 255.42
swapsize => 256.00 MB
swapsize_mb => 256.00
timezone => UTC
uniqueid => a8c09364
uptime => 4 days
uptime_days => 4
uptime_hours => 114
uptime_seconds => 412444
virtual => openvz

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
    inet 127.0.0.2/32 scope host venet0
    inet 192.168.100.147/32 brd 192.168.100.147 scope global venet0:0

# ip route show 0/0
default dev venet0  scope link 

# ip route show
default dev venet0  scope link 

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/void 
jochen@document1.dev:~$ ip route get 8.8.8.8
8.8.8.8 dev venet0  src 192.168.100.147 
    cache  mtu 1500 advmss 1460 hoplimit 64

[joschi]

And here's the output for an OpenVZ container with two veth network devices (network gateway is 176.XXX.XXX.XXX):

facter
architecture => amd64
augeasversion => 0.10.0
facterversion => 1.7.1
filesystems => ext3
hardwareisa => unknown
hardwaremodel => x86_64
hostname => test
id => root
interfaces => eth0,eth1,lo,venet0
ipaddress => 192.168.100.116
ipaddress_eth0 => 192.168.100.116
ipaddress_eth1 => 192.168.101.116
ipaddress_lo => 127.0.0.1
is_virtual => true
kernel => Linux
kernelmajversion => 2.6
kernelrelease => 2.6.32-19-pve
kernelversion => 2.6.32
lsbdistcodename => wheezy
lsbdistdescription => Debian GNU/Linux 7.1 (wheezy)
lsbdistid => Debian
lsbdistrelease => 7.1
lsbmajdistrelease => 7
macaddress => b2:ea:8f:0d:43:c7
macaddress_eth0 => b2:ea:8f:0d:43:c7
macaddress_eth1 => b2:bf:ea:22:ab:00
memoryfree => 489.42 MB
memoryfree_mb => 489.42
memorysize => 512.00 MB
memorysize_mb => 512.00
memorytotal => 512.00 MB
mtu_eth0 => 1500
mtu_eth1 => 1500
mtu_lo => 16436
mtu_venet0 => 1500
netmask => 255.255.255.0
netmask_eth0 => 255.255.255.0
netmask_eth1 => 255.255.255.0
netmask_lo => 255.0.0.0
network_eth0 => 192.168.100.0
network_eth1 => 192.168.101.0
network_lo => 127.0.0.0
operatingsystem => Debian
operatingsystemmajrelease => 7
operatingsystemrelease => 7.1
osfamily => Debian
path => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
physicalprocessorcount => 0
processor0 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processorcount => 1
ps => ps -ef
puppetversion => 3.2.2
rubysitedir => /usr/local/lib/site_ruby/1.9.1
rubyversion => 1.9.3
selinux => false
sshdsakey => [REDACTED]
sshecdsakey => [REDACTED]
sshfp_dsa => [REDACTED]
sshfp_ecdsa => [REDACTED]
sshfp_rsa => [REDACTED]
sshrsakey => [REDACTED]
swapfree => 512.00 MB
swapfree_mb => 512.00
swapsize => 512.00 MB
swapsize_mb => 512.00
timezone => CEST
uniqueid => a8c07464
uptime => 0:02 hours
uptime_days => 0
uptime_hours => 0
uptime_seconds => 156
virtual => openvz

# ip route show 0/0
default via 176.XXX.XXX.XXX dev eth0

#  ip route show
176.XXX.XXX.XXX dev eth0  scope link 
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.116 
192.168.101.0/24 dev eth1  proto kernel  scope link  src 192.168.101.116 
default via 176.XXX.XXX.XXX dev eth0

#  ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT 
    link/void 
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/ether b2:ea:8f:0d:43:c7 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/ether b2:bf:ea:22:ab:00 brd ff:ff:ff:ff:ff:ff

# ip route get 8.8.8.8
8.8.8.8 via 176.XXX.XXX.XXX dev eth0  src 192.168.100.116 
    cache  mtu 1500 advmss 1460 hoplimit 64

[joschi]

So the problem only exists with venet network devices (which are kind of special, see Virtual Ethernet device and Differences between venet and veth) but not with veth devices.

[wolfspyre]

@joschi
Thanks for this output... This brings up a question though:
In the case of a single venet interface, what would you expect the value of network_nexthop_ip to be?

I'm being drawn towards no result, as there is no nexthop IP to provide.

One possible direction to go would be to create another fact 'network_nexthop' as well, and populate that with the ip in cases when our nexthop is an IP, and with the interface in this case. I'm somewhat averse to this, as It feels like code duplication which doesn't provide much functionality. I'm open to being convinced differently however.

Here's an update to the module's fact and spec tests which I think will behave in your environment:
wolfspyre@dfa3183

Can you test it out and let me know if it behaves, or causes some horrible side effect that nobody anticipated?

[joschi]

In the case of a single venet interface, what would you expect the value of network_nexthop_ip to be?

Since Facter cannot find out that information I wouldn't expect to get this fact at all.

But at least I don't want to have Ruby warnings (see initial issue description) to appear in my Puppet output.

[wolfspyre]

That's what I thought. Does the updated fact behave as anticipated?

MobileMail

On Jul 23, 2013, at 3:44, Jochen Schalanda notifications@github.com wrote:

In the case of a single venet interface, what would you expect the value of network_nexthop_ip to be?

Since Facter cannot find out that information I wouldn't expect to get this fact at all.

But at least I don't want to have Ruby warnings (see initial issue description) to appear in my Puppet output.

—
Reply to this email directly or view it on GitHub.

[wolfspyre]

Hi there. Does the updated fact listed here resolve the problem you were
experiencing? I'd like to merge this, and close this issue out if so

On Tue, Jul 23, 2013 at 7:54 AM, Wolf Noble wolf@wolfspyre.com wrote:

That's what I thought. Does the updated fact behave as anticipated?

MobileMail

On Jul 23, 2013, at 3:44, Jochen Schalanda notifications@github.com
wrote:

In the case of a single venet interface, what would you expect the value
of network_nexthop_ip to be?

Since Facter cannot find out that information I wouldn't expect to get
this fact at all.

But at least I don't want to have Ruby warnings (see initial issue
description) to appear in my Puppet output.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-21400613
.

[joschi]

Hi, sorry for the late reply.

Your patch does indeed solve the problem. I do not see the warnings on each Puppet agent run anymore.

[wolfspyre]

Excellent! I've just submitted a PR to merge this in. Thanks again for reporting this and working with us to improve the module.