[quagga-dev 11686] Re: link detect enable

David Lamparter equinox at diac24.net
Wed Oct 29 11:21:15 GMT 2014


On Wed, Oct 29, 2014 at 10:50:02AM +0000, Paul Jakma wrote:
> The only precedent I can think of is we once had a bug in (IIRC) RIP auth 
> where we had to change behaviour incompatibly, and we had to go through 
> several releases with:
> 
> * Release X: Add a "broken behaviour on/off" command, that was on by
>    default and whose state was *always* explicitly written out to config.
> 
> * Release Y: Change the default of "broken behaviour ..." to off.
> 
> * Release Z: No longer explicitly write out the "broken behaviour ..."
>    command, but only if its state was != default.
> 
> Where X, Y and Z weren't necessarily consecutive releases (I can't 
> remember).
> 
> The idea being that those already running ripd and depending on the broken 
> behaviour might upgrade to X and at some point doing 'write file', so 
> getting the "broken behaviour on" command in their permanent config. After 
> which the Y release could change the default without breaking at least 
> some of the X users. If it did break (e.g. new install talking to pre-X 
> neighbours), at least there'd be a strange new command in the config when 
> they investigated.
> 
> Then eventually the Z release finally could stop the command still being 
> written out.

Seems like an useful approach to me.  Config default versioning kinda
tries to do this on a broad scale and without the intermediate delay
caused by not needing releases in the middle that write out everything
explicitly.

NB: both your XYZ scheme and config default versioning only works for
users who use "write memory" to save their configs.  But some people
hand-edit config files, and some automatically construct them from
scripts...

(I'd claim config default versioning handles these cases slightly
better; though in both script and hand-writing configs it depends on
whether the creator notices the existence of the command)

> That's very tedious, but every ripd auth user depended on the borken 
> behaviour and it wasn't their fault - it was a stupid ripd bug (mine I 
> think, not 100% certain).
> 
> ---
> 
> In this case, the default is affecting all users, and every new user has 
> to learn about the desirability of setting this flag. However anyone 
> depending on it is almost certainly doing so by mistake.
> 
> regards,
> -- 
> Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
> Fortune:
> The grass is always greener on the other side of your sunglasses.




More information about the Quagga-dev mailing list