Rack furniture

[hendrikbl]

I know this issue/idea has been discussed a few times (#417, #1018, #10508) but I still want to elaborate why I think rack furniture would be a valuable addition.

Our situation
I work in city government where we currently have 200+ sites and 1000+ devices in netbox. Most of the sites only have network equipment and no servers or something like that. A typical rack in one of these sites has one fiber patch panel, n x 24 copper patch panels and n/2 x 48 port switches. So the bulk of these racks units are copper patch panels connected to edge ports on the switches.

Current solution
Netbox is only used for "real" devices (servers, switches, routers, etc.) and fiber patch panels. For the latter we use the front and rear ports to document how our switches are connected. It works great.
When it comes to copper patch panels: we don't really care where ports are connected. What we care about is a rack view where we can see the utilization of a rack and can see how many patchpanels/blanks/cable management etc. are in there and how much space is left. We used visio in the past for that but it created way too much overhead so we switched do excel. It gets the job done quick and easy but it is missing the integrity of netbox and leads to duplicate data (once in netbox and once in excel).

The Problem
What we want is a rack view with everything inside the rack, devices and non-devices. Most discussions I read about this topic led to the same solution: Just create a device type for lets say a 24 port patch panel, create a device for each of those panels and place it in your racks. In our case, this would lead to about 1500 (!!) 24 patch panel devices alone. This is not couting blanks and other rack furniture. We simply don't want that much bloat only for having a nice rack view and some utilization numbers.

Possible Solution
A solution for that would be a new model (GenericDevice or RackFurniture or something like that) that can be used in racks but does not need to be instantiated.
As far as I can tell, the only changes needed on existing models would be the calculation methods on the Rack model. Those would need to respect not only the devices but also the rack furniture when calculating utilization or weight.

We thought about implementing this as a plugin, but the required changes to the rack model and the existing ui made this impossible.

I'd be happy to hear some thoughts from the community if that's only a niche problem or if others would like a feature like this too.

[chris240189]

While I don't see a problem in creating the patchpanels etc (programmatically of course), have you thought about using rack reservations to get the used and free space calculated correctly?
https://netboxlabs.com/docs/netbox/en/stable/models/dcim/rackreservation/

Or have a look at the upcoming 4.1 release of netbox that has rack types. maybe you can define a default rack type, that has your common stuff already installed

[hendrikbl]

Imo creating devices for that is a workaround at best. While rack reservations may work for rack utilization, it leads to confusion when actually wanting to reserve something.

I looked at rack types. For me it doesn't seem like there is a way to predefine rack contents. Or am I missing something?
While that would not solve my actual problem, it would be a nice feature on its own.

I still think - especially with the new rack group on the 4.1 ui - that adding a model for rack furniture would be very useful for a lot of people.

[chris240189]

I still don't know why you call creating patch panels as devices a workaround?
I mean, you already have fiber patch panels in there if I understood you correctly, why treat copper patch panels differently? Just give them a proper device role so you can filter them if you get clutter in exports or table views.
Do you run into performance issues or are you on a paid plan with device limit?

[hendrikbl]

Okay, I agree that having patch panels as devices is valid because they can actually contain more information than just using a u in a rack.

But what about things like cable management and shelves? I can't think of anything else these could provide than just being there to fill my rack view to accurately document the real world rack.

While I understand that I could create devices and filter them and that would probably work and not be that much of a problem, I still think that from a data model perspective that this isn't what the device model is intended for and that a rack furniture feature would be a valuable addition.

[candlerb]

I create devices for cable management and shelves. It works fine and doesn't cause me any problems. If you want it to be pretty, you can even upload front images for these devices.

I can't think of anything else these could provide than just being there to fill my rack view to accurately document the real world rack

That's fine. A device with no interfaces (and hence no IP addresses etc) doesn't really consume any resources other than one entry in the dcim_device table. If you had a separate model for rack furniture it would use just as many resources.