[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Network configuration future
From:       Steven Whitehouse <swhiteho () redhat ! com>
Date:       2012-08-29 15:48:16
Message-ID: 1346255296.2704.28.camel () menhir
[Download RAW message or body]

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.

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.

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.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]