/etc/network/routes updated on every run

[ingardm]

I've got the following config:
network_route { 'default':
ensure => 'present',
gateway => 10.0.0.2,
interface => 'bond0',
netmask => '0.0.0.0',
network => 'default',
}

resulting in the following file:
root@myserver:~# cat /etc/network/routes

HEADER: This file is is being managed by puppet. Changes to

HEADER: routes that are not being managed by puppet will persist;

HEADER: however changes to routes that are being managed by puppet will

HEADER: be overwritten. In addition, file order is NOT guaranteed.

HEADER: Last generated at: Mon Mar 24 13:23:26 +0100 2014

default 0.0.0.0 10.0.0.2 bond0
default 0.0.0.0 10.0.0.2 bond0

and on each puppet agent -t run i get:
notice: /Stage[main]/Site000::Profiles::Network::Lacp/Network_route[default]/ensure: created

This is on ubuntu precise. ifupdown-extra is installed.

[pieterlange]

This is (probably?) a more of a documentation bug. Using sudo puppet resource network_route on a node will list you the currently defined routes. You'll probably see a route with default/0 as title.

It might be slightly counter-intuitive but i think you could (should?) be using:

network_route { 'default/0':
  ensure => 'present',
  gateway => '10.0.0.2',
  interface => 'bond0',
  netmask => '0.0.0.0',
  network => 'default',
}

@adrienthebo: is this as designed? I'm using this and i'm fine with it, but the README.md lists a network_route { 'default': as example for RedHat.. so i get why people might get this wrong.

[jyaworski]

Hello:

What's the status of this issue? I'm just pinging old issues.

[pieterlange]

So i see. Like i said back in 2014, i think this is a documentation bug. I don't have access to a redhat machine with puppet to test though. The README.md still lists example routes without a CIDR netmask spec though

[rski]

I happened to run into this last night while looking into another bug. It won't be updated if network is set to 'default' and the name is 'default', so this seems to have changed since the bug was opened. For other cases it might, since when parsing the files it names the discovered resources as $network/$netmask. This is indeed not clear in the documentation and should be explained.

The actual line can be found here

[rski]

It looks like the debian provider will use default/$netmask while the redhat only default. If the route is not the default route, both will (from the source comments) use the CIDR version of the target as :name.
This is an issue, because there is an inconsistency between debian and rh and the same resource can't be named to work both for rh and debian. I'll have a pr for this ready today, along with the documentation update, but it looks like it might be slightly backwards incompatible.

[rski]

It is ready, but it seems to make #66 more prevalent so I'll leave it aside for a bit and work on that first.

[rski]

should be ok now as long as you name default routes 'default' and give them a 0.0.0.0 netmask