Version 2.0.0pre0

[Ondrej Zajicek]

On Thu, Dec 08, 2016 at 05:42:01PM +0100, Martin Mares wrote:
> Hello, world!\n
> 
> > I think that we should expand static protocol to allow adding or deleting
> > routes interactively. There are some problematic behavioral details in
> > it; e.g., how we should handle interactive removal of a route from
> > configuration. Should we have two independent sets of routes, one
> > added/removed by reconfiguration, one interactively? Or should we allow
> > to remove interactively one from configuration? If so, should it respawn
> > during reconfiguration?
> 
> Maybe define a separate protocol which exports routes added/removed online?

Hi

That was one of early ideas, but such protocol would share ~80% of code
with static protocol and behavior-wise it is just equivalent to the first
case (two independent sets) with one more protocol in config file.

Two independent sets is a simple model, i would prefer that. But i wonder
whether it isn't just unnecessary restrictive. For example a user
currently sets some static routes in a boot script using ip command, it
can also change or remove them interactively without changing the
persistent state (the boot script). If the user replaces that with BIRD,
it loses that ability [*].

Another alternative would be to have two behaviors (either configurable
for a static protocol, or static and another protocol), where the first
would be like a static protocol, could be modified interactively, but
would always reset to configured state during reload, while the second
would initialize routes from config only during the start, not during
reconfigure, so routes could be added/removed interactively without
losing them due to reconfiguration.


[*] Disregarding some clumsy ways like copy config file to /tmp, edit it
and reconfigure from that copy; or use some script to preload static
routes to BIRD instead of specifying them in the config file so they
could be changed interactively later.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."