facter 3 and linux disagree about interfaces

[Fabrice Bacchella]

On a linux, if I enumerate interfaces using standards tools I get :

~# ip link list

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000

    link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff

3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000

    link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff

4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 

    link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff

~# cat /proc/net/dev

Inter-|   Receive                                                |  Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed

    lo: 3406986600 26540155    0    0    0     0          0         0 3406986600 26540155    0    0    0     0       0          0

  eth0: 40938625356 197161174    0    0    0     0          0   1254629 626979237863 480085481    0    0    0     0       0          0

  eth1: 72695854413 260987060    6    0    0     6          0   1254612 699024977778 507216135    0    0    0     0       0          0

 bond0: 113634479769 458148234    6    0    0     6          0   2509241 1326004215641 987301616    0    0    0     0       0          0

I don't use ifconfig any more, it's deprecated since ages.

But with facter I got one more :

~# /opt/puppetlabs/bin/facter interfaces

bond0,bond0:1,eth0,eth1,lo

Because bond0 has two interfaces :

~# ip addr list bond0

4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 

    link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff

    inet xxx/20 brd xxxx scope global bond0

    inet xxx/20 brd xxx scope global secondary bond0:1

In full structured view I get

networking => {

  ....

  interfaces => {

    bond0 => {

    },

    bond0:1 => {

    },

  },

}

I would expect something like:

networking => {

  ....

  interfaces => {

    bond0 => {

      [ ip => ]

      [ ip => ]

    },

  },

}

Is that a bug or a feature ?

My view it's bug, because when I ask for interfaces, I mean interfaces, not interfaces and friends. But it might be different on other OS.

In full struc

[Peter Huene]

I agree that Facter could do a better job merging the secondary "interface" into the primary one here.  It shares the networking fact code with a few other platforms (mainly OSX and the BSDs) and it currently doesn't do any specific logic for Linux to merge bonded interfaces together.

We could potentially address this in a backwards-compatible way by adding a "secondary"  field to a interface entry that is an array of the remaining secondary addresses.  Thus, the "bond0:1" interface would be effectively moved to "networking.interfaces.bond0.secondary.0".  Would that make sense to do?

 

In full struc

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/C5E27602-09BE-42A1-8040-C7B764116A06%40orange.fr.
For more options, visit https://groups.google.com/d/optout.

--

Join us at PuppetConf 2015, October 5-9 in Portland, OR - www.2015.puppetconf.com 

Register early to save 40%!

[Fabrice Bacchella]

I agree that Facter could do a better job merging the secondary "interface" into the primary one here.  It shares the networking fact code with a few other platforms (mainly OSX and the BSDs) and it currently doesn't do any specific logic for Linux to merge bonded interfaces together.

I don't thinks that specific to bonded interfaces, a plain eth0 would work the same way.

We could potentially address this in a backwards-compatible way by adding a "secondary"  field to a interface entry that is an array of the remaining secondary addresses.  Thus, the "bond0:1" interface would be effectively moved to "networking.interfaces.bond0.secondary.0".  Would that make sense to do?

That's sound good. And perhaps add a primary: "..."  to secondaries too.

So the structured fact will look like :

networking => {

  ....

  interfaces => {

    eth0 => {

secondaries =>  [ "eth0:1" ]

    },

    eth0:1 => {

primary => "eth0"

    },

  },

}

So it would be easy to filter interfaces in template or other places

[Peter Huene]

I was thinking more along the lines of:

networking => {

  ...

  interfaces => {

    eth0 => {

      ip => "xyz.xyz.xyz.xyz",

      ...

      secondary => [

        {

          ip => "abc.abc.abc.abc",

          ...

        },

        ...

      ]

    }

    ...

  }

  ...

}

Thus there would be no "eth0:1" in the interfaces list; it would just show up as the first element in the secondary array.  e.g. eth0:1 becomes eth0.secondary.0, eth0:2 becomes eth0.secondary.1, etc.

Thoughts on this approach? It would better model the output of command line tools that don't distinguish interfaces between "iface" and "iface:x".

Alternatively, we could keep eth0:1 in the list and have a reference to the primary interface like you suggested.  I'm open to either approach.

 

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/DE6C8BA7-3685-42A0-BFAA-E4E82E35B557%40orange.fr.

For more options, visit https://groups.google.com/d/optout.

[Fabrice Bacchella]

> Le 21 juil. 2015 à 20:33, Peter Huene <peter...@puppetlabs.com> a écrit :

>
> Thus there would be no "eth0:1" in the interfaces list; it would just show up as the first element in the secondary array. e.g. eth0:1 becomes eth0.secondary.0, eth0:2 becomes eth0.secondary.1, etc.
>
> Thoughts on this approach? It would better model the output of command line tools that don't distinguish interfaces between "iface" and "iface:x".
>
> Alternatively, we could keep eth0:1 in the list and have a reference to the primary interface like you suggested. I'm open to either approach.

I prefer to have no eth0:1 in the interfaces too, but it can break comptability with legacy code. I'm currently switching to facter 3, so that's not a problem for me, other might disagree.

[Peter Huene]

Facter 2.x parsed the output of ifconfig, which I suspect did not list secondary interfaces in the output or, worse, Facter parsed the output such that the addresses of an interface were actually overridden by subsequent lines of output (historically, there were a few bugs around that).

Facter 3.x uses the getifaddrs function to enumerate the interfaces directly from the kernel, so it isn't susceptible to that particular problem, although as you've discovered it returns unique interfaces for what should be logically considered "secondary".

If you have access to Facter 2.x on this same system, I'd be curious to see if it would output the secondary interface / address information.  If not, I think we could consider Facter's 3.x behavior to be a bug and fix it by moving the secondary interfaces to where they belong.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6F5D8E9E-DC38-402B-B254-85949A7DDC81%40orange.fr.

For more options, visit https://groups.google.com/d/optout.

[Fabrice Bacchella]

If you have access to Facter 2.x on this same system, I'd be curious to see if it would output the secondary interface / address information.  If not, I think we could consider Facter's 3.x behavior to be a bug and fix it by moving the secondary interfaces to where they belong.

On facter2, I get the secondary interface (on another server):

~# ip addr list

    link/ether XXX brd ff:ff:ff:ff:ff:ff

    inet XXXX brd XXX scope global bond0

       valid_lft forever preferred_lft forever

    inet XXX brd XXX scope global secondary bond0:git

       valid_lft forever preferred_lft forever

~# facter interfaces

bond0,bond0_git,eth0,eth1,lo

~# facter -v

2.4.4

[Peter Huene]

Shucks, I was hoping Facter 2.x wasn't reporting the secondary interface so we could fix it such that it doesn't appear in the interfaces list and maintain backwards compatibility.  It sounds like we may have to take your earlier suggestion of tying secondary and primary interfaces together via additional attributes.

~# facter -v

2.4.4

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/A4D6EAFC-A729-419C-815A-AAC16C7056A0%40orange.fr.

For more options, visit https://groups.google.com/d/optout.