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

[Lennart Poettering]

On Thu, 29.01.15 18:49, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> В Thu, 29 Jan 2015 15:10:16 +0100
> Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> пишет:
> 
> > On Thu, Jan 29, 2015 at 02:05:10PM +0000, Rauta, Alin wrote:
> > > What if we don't use the "*" for now and document "BindCarrier" accordingly to be a list of port names and no wildcard ?
> > > Then, if it's the case we can add such "*" support for "BindCarrier" and think about all those corner cases ?
> > 
> > What about interpreting the wildcard dynimically instead? If
> > eth3 goes down, look at all interfaces which have BindCarrier set, and
> > check with glob if their BindCarrier setting matches eth3, and act
> > accordingly.
> 
> This means that every time any interface (dis)appears you must go
> through all existing BindCarrier statements and check whether they
> apply. This is really ugly. For this reasons I believe uplink group
> should be first class citizen also internally.

Well, I really don't see how this would be "ugly". When we
design interfaces we primarily should keep the user's PoV in mind, and
only secondarily the ease of implementation. 

I mean, if you are concerned about scalability (because each new
interface means we need to check O(n) other interfaces), then there
are certainly better ways to optimize that (for example, via a prefix
hash table or so). But either way, I doubt this is really worth it for
now, it would be premature optimization. We are not talking 10K of
ports here for now. And if we want to support that one day, then
there's ample time to add such a prefix hash table by then...

> And how do you set properties for it? Which of BindCarrierMode
> statements in different link (or are they network?) files apply if
> they differ? What if you need to add more properties?

I am pretty sure BindCarrier= and BindCarrierMode= should be .network
properties. And they only apply to each specific link the .network
file is applied on. And since we only apply a single .network file per
link at any time there's no ambiguity here at all.

> What about
> 
> DownlinkCarrierGroup=1 in upstream interface
> UplinkCarrierGroup=1 in downstream interface
> 
> This creates uplink group 1 and binds interfaces to it. Now you only
> need to care if there is another interface definition that has the same
> group number.

I fully agree with Zbginiew that numeric IDs as identifiers for user
objects are a bad idea. 

> But you still need ability to set group properties (although in
> practice every switch I have seen is using policy "all" - anyone can
> give compelling use case for using "any"?), so yes, we may need support
> configuration object for it. But the first step could be default to
> policy "all" which does not require any configuration.

I fail to see what properties these "groups" would require that
couldn't be better be just be .network file properties...

But yeah, I am pretty sure that BindCarrier= would be the first step,
and BindCarrierMode= only the next step should the default policy of
"all" not be sufficient for all usecases...

Lennart

-- 
Lennart Poettering, Red Hat