[opensource-wg] NetBox

Anno domini 2020 Sander Steffann scripsit:

Hi Sander, *

> I have the feeling a lot of people are using NetBox, and I wonder how
> you are all dealing with things that are not supported or not working
> the way you want/need.

Yep, guilty as charged. I added some custom fields, put some more complex
stuff into config contexts, and added some tags for flags/boolean kind of
things where I could easily generate things from in my yolomation.

> My personal biggest requirement has been to be able to trace DWDM
> connections accross circuits and patch panels. I became a NetBox
> maintainer for a while and worked on getting this implemented right in
> NetBox 2.8 and 2.9. But now 2.10 has been released, and no path trace
> will traverse a circuit anymore. I have no idea why it's been broken
> again, and to be honest I don't have the energy to go back and fix it
> *again*. Jeremy (NetBox "manager") just told me to file a feature
> request to restore the broken functionality, which is not very helpful.

Yeah, I've already seen this in the release notes and didn't upgrade
yet to not lose this feature for CWDM / dark fibers (-> circuits) and
stuff.

>From the release notes[0]:

--snip--
Improved Cable Trace Performance (#4900)
All end-to-end cable paths are now cached using the new CablePath
backend model. This allows NetBox to now immediately return the
complete path originating from any endpoint directly from the
database, rather than having to trace each cable recursively. It also
resolves some systemic validation issues present in the original
implementation.

Note: As part of this change, cable traces will no longer traverse
circuits: A circuit termination will be considered the origin or
destination of an end-to-end path.
--snip--

I think this is a huge step back but have the same feeling that
arguing with the maintainer(s) isn't really fruitful most of the time :(

> I was wondering: how do other NetBox users deal with this? Maintain
> your own fork (there seem to be MANY forks on GitHub), stick with a
> version that works, ...?

For now I'm sticking with 2.9.x but eventually there needs to be a
solution which is save to update.

> I know there are people already looking to do a LibreNMS-style fork of
> NetBox and continue development under more community-friendly
> management. Would people be interested in something like that? Because
> that's definitely the style that I want to contribute to :)

I'm thinking of forking netbox for a while not as I have to work around for
a number of things which could IMHO easily be added natively.  From my point
of view the most pressing things are
 * custom fields on interfaces (which are "not required" as the
   maintainers think) and where I work around by having an ifaces dict
   in config contexts (primary for GRE tunnels)
 * Modelling Wifi PTP connections (which is accepted, see #3979)
 * more API stability so you don't have to update your consumer
   systems every other minor release (a bit exaggerating, but not much)
 * Support for bridges (I would implement that like LAGs)

As I have quite a bit on my plate as it is I'm not too keen on doing
all that but if there were a mostly compatible fork with the mentioned
spirit I'd be up for adding stuff like the briding as it would save me
quite a lot of pain by working around it by tags/config contexts.

Thanks for you effors on the CWDM/DWDM/cabling stuff, I followed that
a bit in the issues; it's very helpful and very much appreaciated <3

Best
Max

[0] https://github.com/netbox-community/netbox/releases/tag/v2.10.0