sileht/bird-lg

Looking for new maintainers / project reboot

zorun opened this issue · 7 comments

zorun commented

sileth has not been active on the project for several years. I have been doing some interim maintenance, but I can't commit to spend a lot of time on the project.

The situation is not really good at the moment, both on the community side:

  • there are unaddressed security issues (e.g. #63)
  • code proposals take several months to be reviewed, or are not reviewed at all, discouraging new contributors

and on the technical side:

  • the code is aging and is becoming hard to maintain / debug (especially the bgpmap visualisation)
  • we need an API (see #84)
  • the communication between the backend and web UI frontend is really messy, it would really benefit from an API
  • the project is not well-adjusted for general usage: either it provides too much (dependency on memcached), too specific ("domain" concept), or too little (customization is difficult and requires to hack the code)
  • as a result, many people modify bird-lg to suit their needs, creating a lot of divergence and not contributing energy to the "main" project

This calls for a "reboot" of the project, either by investing more maintenance energy to be able to transform it, or by re-designing / rewriting (parts of) the project from scratch.

In both cases, it requires a community of motivated people! If you are interested in such a "reboot", please reply to this ticket to discuss.

Deleted user commented

Hi there!

Consider me interested. I have been using the burble bird-lg fork for a few weeks and made several modifications, but I decided to scrap it after all and write something own with focus on usability and security. Maybe this can be reused for a new community-driven bird-lg replacement.

My bird-lg fork: https://github.com/petabyteboy/bird-lg
My new project: https://git.petabyte.dev/petabyteboy/rusty-lg

zorun commented

Thanks @petabyteboy . Is your new project focused on the same needs as bird-lg, or something simpler?

zorun commented

To start a discussion on frontend-backend communication: I just remembered about this project https://github.com/inex/birdseye from @inex

It serves the same purpose as lgproxy.py, but it has a nice JSON API (example here: https://www.inex.ie/rc1-cork-ipv4/ ). It's written in PHP.

Deleted user commented

Thanks @petabyteboy . Is your new project focused on the same needs as bird-lg, or something simpler?

It is focused on the same needs with an additional requirement to properly visualise IGP routes.
Having a JSON API for the router seems like a great idea first, but I prefer not to run any more complex parsing logic on the router. My implementation keeps the simple lgproxy, and adds a similar JSON API to the looking glass server. This means the parser implementation has to be updated in one place only, and the routers don't have to execute the a lot of complicated logic.

samip5 commented

I just want to mention Hyperglass here. https://github.com/checktheroads/hyperglass

It does not have the "show protocols" thing, but other than that it's good, and written in Python.

zorun commented

I had a look at Hyperglass and it looks like a nicely organised project (code/tests/etc). It is nearing a v1.0 from what I can tell. It supports many backends (including Bird and FRR) which is impressive.

However I find its UI a bit "crude" and it lacks a BGP map. For me this is the killer feature of bird-lg.

Design-wise, Hyperglass used to have a Linux agent running on the router itself (same idea as lgproxy). But they now switched to simply connecting over SSH. I think it's a good idea because it delegates authentication to SSH and requires no software installation on the Linux router. Performance might be an issue though (SSH connection multiplexing might help). Security should be OK by forcing birdc -r as the only usable command server-side, with usage along the lines of:

echo "show protocols" | ssh linuxrouter birdc -r
zorun commented

I intend to keep doing low-intensity maintenance on bird-lg, but nothing big (maybe python3 support at maximum).

If you are interested in investing time in the project, the "reboot" offer still stands! Here is what I think are the most needed big changes (but this can and should be discussed):

  • add an API to bird-lg (#84)
  • rewrite the web UI so that it exclusively uses the API (clean frontend / backend separation)
  • rework bird-lg <--> router communication (e.g. using the SSH idea, @petabyteboy 's argument about avoiding complexity on the router is good)