[dev] FRR Packaging: existing guidelines and future plans

[Scott Leggett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170607/afb28305/attachment.sig>