Network configuration future

[Dan Williams]

On Wed, 2012-08-29 at 16:48 +0100, Steven Whitehouse wrote:
> Hi,
> 
> I wonder if one way to deal with the network configuration issue is to
> try and help different configuration systems work with each other,
> rather than to try and create one system which does everything. Last
> time I looked into this there were various things which could be done to
> allow peaceful coexistence of various configuration tools, but which
> were missing.

Obviously we can add a couple of abstraction layers to avoid making hard
choices and continue to funnel effort into multiple competing projects.
That provides choice, but also increases complexity and the number of
gaps that things fall through and that problems are caused by.

> One of these is related to routing. Routes can be tagged with an
> originator protocol (/etc/iproute2/rt_protos) with the default being
> "kernel" for routes which are generated automatically, say on interface
> being brought up. This means that utilities which do some form of
> dynamic routing (and I include NetworkManager, dhcp clients, etc in
> this) should only remove or change routes which are either marked
> "kernel" or which are marked with their own protocol id. I brought this
> issue up some time ago (I did look for a reference but didn't find one
> immediately), but without seeing much enthusiasm for resolving it.

I think mainly becuase it's orthogonal to the problem.  NM already
doesn't touch routes on interfaces it doesn't manage

The real problem is the *default* route, and that's a shared resource.
Tagging doesn't help here because only one thing (whatever that is)
really should be handling the default route, precisely because it's a
shared resource.

It wouldn't be nice to create a higher priority default route than the
one created by tool A, just like it wouldn't be nice for tool A to
create a higher priority default route than that created by tool B.  How
do you mediate between them?  We attempted to make NetworkManager that
thing, but obviously that's incomplete since it doesn't have knowledge
of all the interface on the system in some cases.

But the thing that handles the default route and DNS priority *does*
need to have a pretty good knowledge of all interfaces on the system,
and their relative priority.

Dan

> My point is not so much that this particular issue should be fixed (and
> maybe it has been since it is a while since I last checked) but that by
> careful use of the available functions (and maybe with the odd extension
> here and there) it should be possible to allow many different tools to
> cooperate with each other. I'm just using the route issue as an example.
> 
> Obviously there needs to be some coordination when it comes to dealing
> with an interface coming up and which particular tool will deal with the
> set up, but there is still scope for allowing multiple tools to
> cooperate too. That way we can have specialist tools to deal with the
> less common situations without needing to clutter up those tools dealing
> with the more common case with more advanced features.
> 
> So my take on the problem is to consider how it would be possible to
> have different tools cooperating in the same space, and then maybe to
> extract the common functions which allow this into a small library which
> could then be used by each tool.
> 
> I'm not sure if this is useful in the context of the original post, but
> it is what it brought to mind while I was reading it,
> 
> Steve.
> 
>