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:lenn...@poettering.net] Sent: Friday, May 15, 2015 7:34 PM To: Rauta, Alin Cc: systemd-devel@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.ra...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
