Personally, I don't really like this feature very much.

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).

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.

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...


> 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------


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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to