[systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
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
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 Poettering, Red Hat
More information about the systemd-devel