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

[Rauta, Alin]

Hi Lennart,

Thanks for the answers.

One more questions. Just a curiosity of mine.

Currently, a user has to write scripts if he wants to save the run-time configuration in networkd format or to use a configuration management tool like chef for example.
Even with the latter, the user still needs to write scripts.

What about saving the run-time configuration in networkd format with "networkctl" maybe ?
Something like "networkctl save" or "networkctl save config" with extensions to provide per port configuration saving, output directory for saved configuration and so on ... ? 

Best Regards,
Alin

-----Original Message-----
From: Lennart Poettering [mailto:lennart at poettering.net] 
Sent: Friday, May 15, 2015 7:34 PM
To: Rauta, Alin
Cc: systemd-devel at lists.freedesktop.org; Tom Gundersen; Belkind, Nadav
Subject: Re: networkd: dbus API for networkd reconfiguration at run-time

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