Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Yes. It makes sence. Thanks, Alin -Original Message- From: Tom Gundersen [mailto:t...@jklm.no] Sent: Thursday, May 21, 2015 3:20 PM To: Rauta, Alin Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Belkind, Nadav Subject: Re: networkd: dbus API for networkd reconfiguration at run-time On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin alin.ra...@intel.com wrote: 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 ... ? Not entirely sure I understand the question, but this is what I have in mind: we support three config sources at the moment: stuff in /lib which is shipped by packages, stuff in /etc that is provided by the admin and is persistent between reboots and stuff in /run which is lost on reboot. Our future API should have a switch allowing the config we apply to either be persistent (written out to /etc) or ephemeral (written out to /run), so that any config in networkd is backed by a config file somewhere. Does that make sense? Does it answer your question, or is there some other type of config you would like to write out? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin alin.ra...@intel.com wrote: 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 ... ? Not entirely sure I understand the question, but this is what I have in mind: we support three config sources at the moment: stuff in /lib which is shipped by packages, stuff in /etc that is provided by the admin and is persistent between reboots and stuff in /run which is lost on reboot. Our future API should have a switch allowing the config we apply to either be persistent (written out to /etc) or ephemeral (written out to /run), so that any config in networkd is backed by a config file somewhere. Does that make sense? Does it answer your question, or is there some other type of config you would like to write out? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
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
Re: [systemd-devel] 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
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Hi guys, Any updates on this one ? Thanks, Alin From: Rauta, Alin Sent: Thursday, April 30, 2015 1:57 PM To: systemd-devel@lists.freedesktop.org; Tom Gundersen; lenn...@poettering.net Cc: Belkind, Nadav Subject: networkd: dbus API for networkd reconfiguration at run-time 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) ? What extensions to existing networkd functionality would the dbus API bring ? Second, regarding BindCarrier= functionality, would dbus API make it possible to modify the string content or the bind carrier functionality at run-time ? 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 ? Thank you in advance, Alin Rauta Software Applications Engineer +353 (0) 87 101 8449 Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
