starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

dcim - racks - manufacturer/model option? #8170

New Issue
Closed
opened 2025-12-29 20:33:24 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:33:24 +01:00
Owner
Copy Link

Originally created by @ITJamie on GitHub (Jun 7, 2023).

Originally assigned to: @arthanson on GitHub.

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

Originally created by @ITJamie on GitHub (Jun 7, 2023). Originally assigned to: @arthanson on GitHub. ### 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_
adam added the status: acceptedtype: featurecomplexity: high labels 2025-12-29 20:33:24 +01:00
adam closed this issue 2025-12-29 20:33:25 +01:00
adam commented 2025-12-29 20:33:25 +01:00
Author
Owner
Copy Link

@justin-davisibm commented on GitHub (Jul 28, 2023):

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.

@justin-davisibm commented on GitHub (Jul 28, 2023): 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.
adam commented 2025-12-29 20:33:26 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 27, 2023):

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.

@github-actions[bot] commented on GitHub (Oct 27, 2023): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:33:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 6, 2023):

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?

@jeremystretch commented on GitHub (Nov 6, 2023): 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?
adam commented 2025-12-29 20:33:26 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Nov 6, 2023):

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.

@ITJamie commented on GitHub (Nov 6, 2023): > 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.
adam commented 2025-12-29 20:33:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 9, 2024):

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.

@jeremystretch commented on GitHub (Jul 9, 2024): 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.
adam commented 2025-12-29 20:33:27 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Jul 9, 2024):

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?

@ITJamie commented on GitHub (Jul 9, 2024): 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?
adam commented 2025-12-29 20:33:27 +01:00
Author
Owner
Copy Link

@justin-davisibm commented on GitHub (Jul 10, 2024):

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.

@justin-davisibm commented on GitHub (Jul 10, 2024): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: high status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#8170
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?