Hi David, On 2017-06-06.18:56, David Lamparter wrote:
On Sat, Jun 03, 2017 at 10:23:12PM +1000, Scott Leggett wrote:
I see that on your wiki[0] and in at least one recent merge[1] that you are moving towards a single system service controlling multiple daemons.
Yes. There are several reasons for this; the first one is actually this:
[quote moved]
On a totally different topic, I thought I saw somewhere that frr is planning to deprecate individual service config files in favour of the integrated config. Is that the case?
Yes, we're moving toward integrated-config mode. This means that daemons do not use individual config files anymore, rather they receive their config from "vtysh -b".
(This is still marked "TBA" in the wiki page.)
In this mode, if the system service manager blindly restarts a daemon, that daemon will sit and do nothing. This obviously can be worked around by scripting, but this just leads to the next problem; FRR features "online" configuration editing, which doesn't interact all that nicely with sudden restarts. Stops are even worse; a stop + config write will currently destroy user configuration.
I should note here that integrated-config mode does not work correctly without watchfrr running, since watchfrr is the entity that will actually write the configuration when the user requests this from the CLI. The functionality is actually in vtysh, but the vtysh process under a user's session does not have the correct credentials to update the configuration file.
My (plan|prediciton) here is that watchfrr will at some point become the mandatory configuration authority across FRR.
Ah, I see. The random bits I've seen are part of a larger plan :-)
I recently removed this feature from the Debian quagga package and replaced it with individual services because I think that the single service controlling multiple daemons is a mistake.
This might be as much an issue of perspective -- these are not multiple independent daemons. It's increasingly becoming much more like a single "daemon" that uses process separation to isolate crashes and scale a bit better. Compare with BIRD, where the functionality of the various daemons we have is all integrated in one binary (which runs twice, for IPv4 and IPv6 each).
It's already the case that all daemons depend on zebra[*], and if the user sets up LDP-signalled MPLS there is also a huge dependeny on ldpd (though only in a functional way, not in a restart-affecting way). BFD will be the same.
A comparison would be sshd launching the sftp-server as needed, or pulseaudio using gconf-helper, or ibus with its subprocesses.
Oh yes, that makes a lot of sense too.
There are some subtle bugs in the old debian service management scripts (e.g. [2],[3]), and having a special new mechanism to learn to control the frr daemons, which is different to the way that every other service works, is quite annoying.
The idea is the opposite - the mechanism to control FRR daemons would be to control watchfrr, which can be started, stopped, restarted, and reloaded. Unfortunately, we're not fully there yet and probably made things worse in the meantime because right now it's an amalgamation of non-fitting puzzle pieces...
Yes, that's what I was a little confused about.. much clearer now, though.
P.S.: the PAM functionality in GNU Zebra never did anything useful, was never improved in Quagga, and still isn't useful in FRR. I strongly recommend disabling it :) [yes, maybe we should hard-disable it in the code until someone makes it useful.]
Thanks for the tip, I'll look into this. And thanks for taking the time to write up such a thorough response to my questions. I look forward to seeing the larger architectural changes in frr take shape! -- Regards, Scott.