[PATCH] Gate boolean protocol options on filename.

João Taveira Araújo joao.taveira at gmail.com
Fri Jul 29 16:09:20 CEST 2016


Hi,

On Fri, Jul 29, 2016 at 3:43 AM, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> On Thu, Jul 28, 2016 at 11:09:08AM -0700, João Taveira Araújo wrote:
>> Hi,
>>
>> Any feedback on this?
>
> Hi
>
> Although i agree that we should have better ways to control BIRD
> programmatically, this feature seems to me like too specific and too
> bizarre.
>
> I see at least two alternatives already awailable:
>
> 1) Use include directive in the usual way (so you would have to use file
> cointaining "disabled;" or appropriate option instead of empty file). If
> you want to treat non-existing files as no change, then just add '*'
> at the end of the file name.
>
>
> 2) Note that include directive looks like regular configuration statement,
> but it is not. It is more like preprocessor directive and can be used
> even inside other statements, like:
>
> protocol ... {
>
>     disabled
>         include "xxx.conf";;
>
> }
>
> Then file xxx.conf should contain just the value (yes or no). This
> approach can be used with any kind of option and seems like more generic
> and more natural approach than gated boolean options.
>
> Note that include has to be on separate line to be parsed correctly and
> there has to be two semicolons (first for include, second for the
> option). This is something that we will probably address in future
> version (so that 'disabled include "xxx.conf";' would be enough).

I'm aware of both options, and I've been using 1) for a while, which
was why I was asking if there was any other way. It feels odd to embed
BIRD syntax into multiple agents that may control BIRD, and makes
integration testing clunkier because I have to verify the contents of
a file. In this respect, "disabled include 'xxx.conf';", while easier
to read, provides no more value for us than the existing solution.

If your main concern is that it only applies to the disabled command,
then I agree that it should be generalized. We also do withdrawal of
prefixes based on the presence of a file ("if
exists("withdraw_anycast")" then ...), because that way configuration
is decoupled from state. It's the only reasonable way we've found for
our configuration to be updated (e.g. adding anycast prefixes)
regularly without affecting our policy (e.g. "don't announce anycast
for this session"). IIRC however there are differences between config
and filter syntax that made "disabled if exists("bla");" less trivial
to implement.

Cheers,
- joao


>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at 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."



More information about the Bird-users mailing list