Support for machine-readable status output

[Kees Meijs | Nefos]

Hi Pascal,

In short: as a BIRD2 user I would like to add it's a (very) good idea
you propose. Probably other users feel this as well.

Regards,
Kees

On 28-04-2020 09:17, Pascal Mathis wrote:
> Hi everyone,
>
> I am wondering if the official maintainers would accept patches for
> introducing machine-readable status output to BIRD. I am asking as there
> definitely is a clear demand for such a solution, as can be seen by
> these previous mailing list posts and projects:
>
> - https://github.com/mchackorg/birdwatcher (JSON API Server)
> - https://github.com/inex/birdseye (JSON API Server)
> - https://github.com/czerwonk/bird_exporter (Prometheus Exporter)
> - https://www.npmjs.com/package/node-bird-routeparse (JSON Generator)
> - https://bird.network.cz/pipermail/bird-users/2018-March/012088.html
> (Previous JSON patch submitted by Alistair Crooks)
> - https://github.com/sileht/bird-lg (BIRD LG with Python Command Proxy)
> - https://bird.network.cz/pipermail/bird-users/2017-June/011362.html
> (Previous mentions of people working on structured output for BIRD)
> -
> https://bird.network.cz/pipermail/bird-users/2011-September/002441.html
> (ML post showing support for JSON output)
>
> All the current solutions mentioned above query BIRD by either running
> the "birdc" executable or directly interacting with the SMTP-like
> protocol on the socket, followed by applying regular parsing magic to
> extract the required information.
>
> While this certainly works, I think adding some kind of
> structured/machine-readable output (e.g. JSON) would greatly simplify
> such integrations in the future and people would no longer have to rely
> on brittle text parsing which can break on any text formatting changes.
>
> Compared to other routing daemons with massive API interfaces (e.g.
> NETCONF or gRPC), BIRD clearly follows a path of simplicity and
> robustness, which is probably a reason why a lot of people are relying
> on it. I personally think that adding a whole API interface for both
> reading and writing would be overkill, as the configuration can already
> be easily templated and reliably reloaded.
>
> To cut a long story short, I would appreciate if BIRD2 would be able to
> output various sorts of information in a structured, machine-readable
> way, e.g. using JSON to print statistics, bgp peers, route lookups and
> more. This could be implemented by adding a flag for JSON output to
> existing commands, as adding a full-blown HTTP server directly into BIRD
> seems like a bad idea.
>
> Would such patches be considered for upstreaming or was there ever a
> decision to not implement this kind of feature? Is maybe someone already
> working on a feature like this?
>
> Thanks in advance for any kind of reply and have a nice day.
>
> Best regards,
> Pascal