[dev] FRR Packaging: existing guidelines and future plans
scott at sl.id.au
Wed Jun 7 09:04:22 EDT 2017
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 and in at least one recent merge that you
> > are moving towards a single system service controlling multiple daemons.
> Yes. There are several reasons for this; the first one is actually
> [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. ,), 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,
> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the dev