Support for machine-readable status output

[Darren O'Connor]

I asked for this back in June 2017, but nothing has come yet (
https://bird.network.cz/pipermail/bird-users/2017-June/011356.html)

On Tue, 28 Apr 2020 at 09:08, Kees Meijs | Nefos <kees at nefos.nl> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20200428/1914f923/attachment.htm>