On Tue, Jul 21, 2015 at 11:06 AM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

> 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
>

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+unsubscr...@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
> <https://groups.google.com/d/msgid/puppet-users/DE6C8BA7-3685-42A0-BFAA-E4E82E35B557%40orange.fr?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
<http://www.google.com/url?q=http%3A%2F%2Fwww.&sa=D&sntz=1&usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw>
2015.puppetconf.com
<http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.com&sa=D&sntz=1&usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog>

*Register early to save 40%!*

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CACZQQfNoQjPaFpCYbmd2hq0Ah69tCmwEhgF8AXLwbZP4k0YywA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to