You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Open Source Working Group

Threaded
Collapse

[opensource-wg] NetBox

User Image

Sander Steffann

2020-12-14 22:37:46 CET

Hi everybody,

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.

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.

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, ...?

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 :)

Cheers,
Sander




User Image

Maximilian Wilhelm

2020-12-15 22:38:53 CET

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

User Image

Sander Steffann

2020-12-16 22:33:52 CET

Hi,

> 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 one of the maintainers for a bit, but even I have given up :(

I'm not even trying to solve 
https://github.com/netbox-community/netbox/issues/5469 anymore.

>> 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.

Same for me.

>> 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!

I know there is a company that is willing to support a NetBox fork with 
money and/or time, but I'll leave it up to them to announce their plans.

> 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

Thanks! Just so annoying that Jeremy breaks it with every thing he does. 
I almost feel like he does it intentionally because it doesn't fit in 
his world view :/

Cheers,
Sander