[LibreQoS] Integration system, aka fun with graph theory

[Herbert Wolverson <herberticus@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1738 bytes --]

So I've been doing some work on getting UISP integration (and integrations
in general) to work a bit more smoothly.

I started by implementing a graph structure that mirrors both the networks
and sites system. It's not done yet, but the basics are coming together
nicely. You can see my progress so far at:
https://github.com/thebracket/LibreQoS/tree/integration-common-graph

Our UISP instance is a *great* testcase for torturing the system. I even
found a case of UISP somehow auto-generating a circular portion of the
tree. We have:

   - Non Ubiquiti devices as "other devices"
   - Sections that need shaping by subnet (e.g. "all of 192.168.1.0/24
   shared 100 mbit")
   - Bridge mode devices using Option 82 to always allocate the same IP,
   with a "service IP" entry
   - Various bits of infrastructure mapped
   - Sites that go to client sites, which go to other client sites

In other words, over the years we've unleashed a bit of a monster. Cleaning
it up is a useful talk, but I wanted the integration to be able to handle
pathological cases like us!

So I fed our network into the current graph generator, and used graphviz to
spit out a directed graph:
[image: image.png]
That doesn't include client sites! Legend:


   - Green = the root site.
   - Red = a site
   - Blue = an access point
   - Magenta = a client site that has children

So the part in "common" is designed heavily to reduce repetition. When it's
done, you should be able to feed in sites, APs, clients, devices, etc. in a
pretty flexible manner. Given how much code is shared between the UISP and
Splynx integration code, I'm pretty sure both will be cut to a tiny
fraction of the total code. :-)

I can't post the full tree, it's full of client names.

[-- Attachment #1.2: Type: text/html, Size: 2233 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 573568 bytes --]