dcim - racks - manufacturer/model option?

[ITJamie]

NetBox version

v3.5.3

Feature type

Change to existing functionality

Proposed functionality

add manufacturer + model option to racks

Use case

some rack models are better suited to some purposes than others. it would be nice if netbox made it native for tracking this information. some racks for example are soundproofed models, some have better cable routing space on the sides etc.

this (could) potentially speed up adding of new racks as some of the existing add new rack fields could move to a manufacturer/model section (dimensions)

Database changes

additional models needed for manufacturer / models for racks (similar to devices)

External dependencies

No response

[justin-davisibm]

For an example:

7014-T42 is a 7014-T42 regardless of how many times I use it. Modeling it once and allowing it to be selected from the rack creation page would be substantially easier than data validation on the frames, or using only custom fields to shim the function in.

• Manufacturer: IBM
• 42U Ascending
• 19" between the rails
• 4 Post rack
• 25.4" wide
• 79.3" tall
• 43.3" deep
• 636lbs empty
• 3521lb capacity

7965-S42

• Manufacturer: IBM
• 42U Ascending
• 19" between the rails
• 4 Post rack
• 23.6" wide
• 79.5" tall
• 44.6" deep
• 391lbs empty
• 3700lb capacity

In addition- standardizing these values would likely assist with floor planning (https://netboxlabs.com/blog/announcing-the-netbox-plugin-bounty-program/) - consistent modeling of rack size would make the rendering of floorplans substantially easier.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[jeremystretch]

Am I correct in understanding that the proposal here is to essentially replicate for racks how the DeviceType model functions for devices, by introducing a new RackType model?

[ITJamie]

Am I correct in understanding that the proposal here is to essentially replicate for racks how the DeviceType model functions for devices, by introducing a new RackType model?

Correct.

Right now there is a lot of duplication of data across racks that could be handled with a simple rackmodel.

[jeremystretch]

It's not clear to me how the attributes of existing racks are meant to be handled when introducing a new RackType model. Consider the DeviceType model as an analog to RackType: Certain device attributes (manufacturer, U height, etc.) are defined on the device type and cannot be altered on individual devices. However, as the RackType model does not yet exist, all rack attributes (height, width, etc.) which we'd expect to define on RackType are obviously defined uniquely on each existing Rack instance.

I see two options, neither of which is particularly appealing:

1. Replicate the relevant fields from Rack on RackType. When provisioning a new Rack, replicate these values from RackType automatically, but permit them to be changed on individual Rack instances. (These fields must remain individually mutable as there is no requirement that an existing Rack be assigned a RackType.) IMO this largely defeats the purpose of the RackType model, as you could very easily end up with racks of the same type with different physical attributes.

2. Move the fields from Rack to RackType. This approach would ensure consistency among all racks of the same type, but require automatic retroactive creation of all unique rack types. This cannot be achieved cleanly as NetBox cannot infer from the available data how to define each RackType instance (name, manufacturer, etc.).

PR #16739 currently takes the approach outlined in the first bullet above. However, I worry about the potential for confusion this approach introduces, both specifically because it deviates from the behavior of device types, and generally because it can easily lead to inconsistency in the data model.

[ITJamie]

IMHO 1 makes the most sense initialy, making it so that if a rack has a rackmodel selected then none of the other fields would be configurable / settable. that would allow existing usecase to continue with a sane migration process, maybe with an eventual forced migration to step 2 in a future version?

[justin-davisibm]

I'm not well versed on the limitations of UI elements in Netbox or the database backend, but my ideal would be:

All existing racks would get an option to add a rack type (if any are defined), and would maintain it's existing size/weight/etc. values until that is changed. If the rack is edited and replaced with a rack type, it inherits the values and the size/weight/etc values become non-editable. This shouldn't break existing racks, and give teams who are well entrenched an option to get their data moved over without major impact.

New racks have an option to add a rack type or use manual sizing.