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 <[email protected]> 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 > >
