[systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

[Lennart Poettering]

On Thu, 29.01.15 15:20, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Wed, 28.01.15 10:13, Rauta, Alin (alin.rauta at intel.com) wrote:
> >
> >> Lennart, on a switch I should be able to configure more than one UFD
> >> group.
> >
> > What precisely does this mean? WOuld those groups be orthogonal?
> >
> > I really would like to avoid introdcuing the "tags" concept for
> > now. Would a solution where you give the uplinks appropriate names
> > (like "uplink0", "uplinkXYZ", "uplink_waldo" and so on) suffice, when
> > you can then refer to them in a .network file you apply to the
> > downlinks as "BindCarrier=uplink*"?
> >
> 
> This has interesting corner case. Let's say you have one interface
> uplink0 and one interface downstream0 that has BindCarrier=uplink*. So
> we bind downstream0 to uplink0 on startup. Later (online) we add
> second interface uplink1 and downstream1 which also has
> BindCarrier=uplink*. But now this one is suddenly bound to *two*
> interfaces instead of one; so they both behave differently.

No. The matches should be reevaluated each time in full.
                                                                                                                                                                                                                                    
Basically each time when we are ready to apply a .network file we
should check the carrier of the interfaces that the .network's
BindCarrier= matches. And each time an interface comes or goes, or
changes its name, we must reevaluate the BindCarrier= settings of all
other interfaces that might match now or might match no longer. This
must be fully dynamic.

> Could also happen if interface fails on startup and is hotswaped or
> otherwise repaired replaced later.
> 
> As such concept of "uplink group" abstracts away direct connection
> between down- and upstream. Each operation would then implicitly
> iterate over interfaces in group; when new interface is added, it
> provides natural place to adjust group monitoring (like set watch for
> it etc). Not so easy with your proposal.

I don't see how an "uplink group" would get us anything here. There's
effectively little difference between propagating carriers from
interfaces to "uplink groups" to other interfaces, and propagating it
directly from interfaces to other interfaces. We can do both fully
dynamic, just one of them is much simpler conceptually than the other.
                                                                                                                                                                                                                                    
I am still pretty convinced that a singular new option, that is
"BindsCarrier=" would suffice to implement the usescases here.

Lennart

-- 
Lennart Poettering, Red Hat