[systemd-devel] networkd: dbus API for networkd reconfiguration at run-time

Lennart Poettering lennart at poettering.net
Fri May 15 11:34:10 PDT 2015


On Thu, 30.04.15 12:57, Rauta, Alin (alin.rauta at intel.com) wrote:

> Hi Tom, Lennart,
> 
> I have some questions regarding dbus API and run-time networkd configuration. I would really appreciate your answers/suggestions.
> 
> First, when upstreaming BridgeFDB support in networkd, I had (in the first place) a patch composed of 2 parts:
> 
> -          One part  for clearing existing configuration;
> 
> -          One part for setting new FDB entries;
> 
> Since networkd doesn't currently clear existing configuration, only the first part of the patch was accepted.
> 
> At that time you said that:
> 
> "In the future we plan to get a dbus API where networkd can be
> reconfigured at run-time (i.e., change which .network file is
> applied to a link), and then it definitely would make sense to flush
> routes and addresses when removing the .network from the link, but
> currently we don't do that at all."
> 
> Do you have any updates or more information on dbus API (how would
> this be actually done, how would work) ?

Not really, nobody hasbeen working on adding any API for this
yet. Given the delays around kdbus I think we should start adding an
API for this now however, but this requires careful consideration I
figure.

I'll try to get this process started with Tom.

> What extensions to existing networkd functionality would the dbus
> API bring ?

Well, initially it will just open up what we already have. i.e. it
will carry an API for creating .netdev interface, and for applying
.link and .network files to interfaces. 

> Second, regarding "BindCarrier=" functionality, would dbus API make
> it possible to modify the string content or the bind carrier
> functionality at run-time ?

Yes, but I think this would be the second step...

> Moreover, we currently have the case where networkd is running and
> has some ports involved in "BindCarrier=" dependencies. Then some of
> this ports are run-time added to a team (link aggregation) device
> (maybe through command line).  In this case the carrier dependencies
> affect the team device functionality creating confusion at one point
> in time (team tries to get the childs up/down, but the functionality
> is affected by the carrier dependencies between childs or between
> childs and other ports outside of the team device).  Would dbus API
> be of any help in this case ? or Do you have any suggestions on how
> to avoid these cases ?

well, sure, if we make BindCarrier= dynamically settable, then you
should be able to cover this nicely...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list