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: santi...@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."
