Hi, On Tue, May 24, 2016 at 7:31 AM, Israel G. Lugo <israel.lugo@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