Add additional option support

[dblessing]

In RedHat there are many more options that can be specified after the interface. For example, you can specify a routing table such as default via 10.0.0.1 dev eth1 table 200. Everything after the interface is so fluid it doesn't make sense to add specific properties for everything. A simple additional_options property is most flexible.

I don't know what or if any additional options are available in Debian but I added support anyway. It certainly shouldn't hurt. If someone else can test the Debian side to see if it's needed that'd be great.

Please let me know if you have any questions.

[adrienthebo]

I've got a few comments on how this property behaves.

First off, the network_config type uses options for setting arbitrary options, I would like to match that convention here for the sake of consistency. Would you be amenable to renaming this to options?

Secondly, right now only redhat and debian are supported but it's possible to add more route providers, and those may not necessarily support additional options. Could you pull out a feature for this property like the options property does for network_config 9https://github.com/adrienthebo/puppet-network/blob/master/lib/puppet/type/network_config.rb#L93)?

Lastly, what sort of values should this be? Should it be a string, hash, or something else? Can we do some sort of validation to make sure we only set reasonable route options? And could you add some documentation of how this could be used and in what cases?

[dblessing]

| Would you be amenable to renaming this to options?
Yes, no problem.

| Can we do some sort of validation to make sure we only set reasonable route options?
Good question. There are a TON of things you can put in for RedHat. It seems pretty daunting to try and validate that. I have no idea what Debian's options are, either. I simply intended the property to be a string of whatever the user wants/needs. Thoughts?

Route section from man page:

ip route { add | del | change | append | replace | monitor } ROUTE
SELECTOR := [ root PREFIX ] [ match PREFIX ] [ exact PREFIX ] [ table TABLE_ID ] [ proto RTPROTO ] [ type TYPE ] [ scope SCOPE ]
ROUTE := NODE_SPEC [ INFO_SPEC ]
NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ] [ table TABLE_ID ] [ proto RTPROTO ] [ scope SCOPE ] [ metric METRIC ]
INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ] ...
NH := [ via ADDRESS ] [ dev STRING ] [ weight NUMBER ] NHFLAGS
OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ] [ rtt TIME ] [ rttvar TIME ] [ window NUMBER ] [ cwnd NUMBER ] [ initcwnd NUMBER ] [ ssthresh REALM ] [ realms REALM ] [ rto_min TIME ] [ initrwnd NUMBER ]
TYPE := [ unicast | local | broadcast | multicast | throw | unreachable | prohibit | blackhole | nat ]
TABLE_ID := [ local| main | default | all | NUMBER ]
SCOPE := [ host | link | global | NUMBER ]
FLAGS := [ equalize ]
NHFLAGS := [ onlink | pervasive ]
RTPROTO := [ kernel | boot | static | NUMBER ]

[dblessing]

If by "validation" you're talking about using a hash and doing validation as in the network_config type you pasted, then yes, that'd be just fine I think. Is that what you meant?

[adrienthebo]

If the possible combinations of values are too complex to validate without going nuts, then just validating that the input is a String would suffice.

[dblessing]

See what you think of the changes.

[dblessing]

Squashed commits.

[adrienthebo]

Thanks for the contribution!