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