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
