[PATCH] Gate boolean protocol options on filename.

[João Taveira Araújo]

Hi,

On Tue, May 24, 2016 at 7:31 AM, Israel G. Lugo
<israel.lugo at tecnico.ulisboa.pt> wrote:
>
> Personally, I don't really like this feature very much.

That's fine, I personally don't like RIP and don't feel obliged to use it...

> On 24-05-2016 14:29, João Taveira Araújo wrote:
>> That's what we do now, and it sucks. You still end up with embedding
>> BIRD syntax outside of BIRD. If you use no wildcards in the include
>> statement, the file must always be present otherwise the config is
>> invalid, so you now shifted the responsibility of managing "disabled
>> on|off" statements elsewhere.
>
> But that is still the case in your approach... The file being present
> dictates whether or not the configuration is valid (does what you want).

If the file is not present, the disabled statement is off. In both
cases the configuration is correct.

> In fact, for me your approach is more dangerous: in the "include" case,
> an accidentally deleted file will trigger an error (which you will
> notice and fix), but in your case it's impossible to tell whether a
> missing file is an error, or you really mean it.

"Accidentally deleting a file" is about the same as "accidentally
putting the wrong value into a stanza". If you want to avoid exposure
to either case, you don't use either feature.

> In my opinion, configuration error (in this case an accidentally deleted
> file) should break rather than silently malfunction.
>
> Put in other words, you now shifted the responsibility of configuring
> the service on the mere presence of files in specific places. That's not
> a very common practice...

I value practicality over common practice, my use cases are wildly
different to most.

>
>> So you have the added complexity of having to read in the file, parse
>> it to see if it matches your understanding of the world, and then
>> rewrite it back out if not. The presence or absence of a file is a
>> much more explicit signalling mechanism.
>
> Either the include file is considered generated content, or it's not.
> That's the point in separating machine-generated configs to another
> file. If the file is human-maintained, your scripts have no reason to
> mess with it; and if it's machine-maintained, the machine can just
> overwrite it.
>
> Presumably, your humans know which files they need to edit in their day
> to day configurations, but it's a trivial matter of adding a header to
> the file in your script, e.g.:
>
> -----8<------
> /*
>  * WARNING WARNING
>  * This file is automatically generated by script-foo.sh.
>  * Any manual edits will be overwritten!
>  */
> disable yes;
> ----->8------

We've used that sort of include script in production for many years.
It's OK (and unavoidable if you want to have dynamically generated
prefix sets), but as an interface it's more complex and as an
abstraction it's less elegant.

Cheers,
- j

>
>
> --
> Israel G. Lugo
> Núcleo de Redes e Comunicações
> Direção de Serviços de Informática
> Instituto Superior Técnico
>