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

Allow for "vertical" U space in/near a rack. #4572

New Issue
Closed
opened 2025-12-29 18:37:46 +01:00 by adam · 11 comments
adam commented 2025-12-29 18:37:46 +01:00
Owner
Copy Link

Originally created by @kirk444 on GitHub (Feb 16, 2021).

Environment

  • Python version: netbox-docker - 3.8
  • NetBox version: netbox-docker - 2.10.4

Proposed Functionality

I would propose a way to model devices that are mounted to a rack/cabinet in a non-standard fashion. I have many racks that include "vertically" oriented U space on the profile reducer. (Specifically, the AMCO Titan DT "MCW Profile Reducer" - https://www.amcoenclosures.com/titandt/ , though I know of at least one other vendor with similar functionality). I currently model these by simply calling devices in them "not racked" but this makes it difficult to actually track which spaces are open/closed. I think this same functionality could likely be extended to other "adjacent" devices, like 0U PDU, which would then allow them to be represented in the elevation view.

In brief, a way to represent devices that are "racked" but are not in the traditional U space.

Use Case

A user with a rack/cabinet that has similar U space on the profile reducers, or has 0U PDU mounted to the sides of the cabinet could use this to visualize their environment.

Database Changes

I suspect this would require a new way to model these spaces, but I am not familiar enough with the database schema to answer conclusively.

External Dependencies

I don't think this will introduce any external dependencies.

Here are some representative images of the mounting location I am referring to:
image
image

Originally created by @kirk444 on GitHub (Feb 16, 2021). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please start a discussion instead: https://github.com/netbox-community/netbox/discussions NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: netbox-docker - 3.8 * NetBox version: netbox-docker - 2.10.4 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality I would propose a way to model devices that are mounted to a rack/cabinet in a non-standard fashion. I have many racks that include "vertically" oriented U space on the profile reducer. (Specifically, the AMCO Titan DT "MCW Profile Reducer" - https://www.amcoenclosures.com/titandt/ , though I know of at least one other vendor with similar functionality). I currently model these by simply calling devices in them "not racked" but this makes it difficult to actually track which spaces are open/closed. I think this same functionality could likely be extended to other "adjacent" devices, like 0U PDU, which would then allow them to be represented in the elevation view. In brief, a way to represent devices that are "racked" but are not in the traditional U space. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case A user with a rack/cabinet that has similar U space on the profile reducers, or has 0U PDU mounted to the sides of the cabinet could use this to visualize their environment. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes I suspect this would require a new way to model these spaces, but I am not familiar enough with the database schema to answer conclusively. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies I don't think this will introduce any external dependencies. Here are some representative images of the mounting location I am referring to: ![image](https://user-images.githubusercontent.com/11370/108122339-bd048880-7069-11eb-8f8c-8d573c906727.png) ![image](https://user-images.githubusercontent.com/11370/108122355-c4c42d00-7069-11eb-97dc-581dc6430de8.png)
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 18:37:46 +01:00
adam closed this issue 2025-12-29 18:37:46 +01:00
adam commented 2025-12-29 18:37:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 24, 2021):

Please describe in the detail the proposed changes to the data model that you envision to support this.

@jeremystretch commented on GitHub (Feb 24, 2021): Please describe in the detail the proposed changes to the data model that you envision to support this.
adam commented 2025-12-29 18:37:47 +01:00
Author
Owner
Copy Link

@kirk444 commented on GitHub (Feb 24, 2021):

I think at it's simplest, a rack could have new (optional) "mounting" locations added for 0U devices (rear-right, rear-left, front-right, front-left) which would indicate the physical location of an installed 0U device (PDU or similar). These could then be represented on the rack elevations.

Optionally, these spaces could have a size (in RU) to mount 1U devices, but the RU would be rotated 90degrees, and would be limited to [rack height in RU]/12. 1RU for each 12RU of the rack they are installed in. An RU added in this manner would be evenly spaced top-to-bottom based on the overall height of the rack. Again, this would allow for the 1RU devices to be represented in the rack elevations.

In summary, each "corner" of a rack (RR, LR, RF, LF) would have a bool (0U mounting available/not available) and an integer for 1RU spaces. This integer would be limited to "[rack RU]/12".

EDIT: fixed some words that got eaten as formatting.

@kirk444 commented on GitHub (Feb 24, 2021): I think at it's simplest, a rack could have new (optional) "mounting" locations added for 0U devices (rear-right, rear-left, front-right, front-left) which would indicate the physical location of an installed 0U device (PDU or similar). These could then be represented on the rack elevations. Optionally, these spaces could have a size (in RU) to mount 1U devices, but the RU would be rotated 90degrees, and would be limited to [rack height in RU]/12. 1RU for each 12RU of the rack they are installed in. An RU added in this manner would be evenly spaced top-to-bottom based on the overall height of the rack. Again, this would allow for the 1RU devices to be represented in the rack elevations. In summary, each "corner" of a rack (RR, LR, RF, LF) would have a bool (0U mounting available/not available) and an integer for 1RU spaces. This integer would be limited to "[rack RU]/12". EDIT: fixed some words that got eaten as formatting.
adam commented 2025-12-29 18:37:48 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Apr 5, 2021):

The racks we are using have space for 3 full-height 0U PDUs on both sides at the back for total of 6 locations. We currently use four of them. I feel that the amount of locations should not be limited to something like "corner", maybe simply specify side (front/back and left/right) and allow unlimited number of items - possibly with an option to choose which U-numbers are used by each item.

@bluikko commented on GitHub (Apr 5, 2021): The racks we are using have space for 3 full-height 0U PDUs on both sides at the back for total of 6 locations. We currently use four of them. I feel that the amount of locations should not be limited to something like "corner", maybe simply specify side (front/back and left/right) and allow unlimited number of items - possibly with an option to choose which U-numbers are used by each item.
adam commented 2025-12-29 18:37:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 7, 2021):

I don't see a way to implement this idea without completely overhauling the way we currently model rack units. Which isn't to say that would necessarily be a bad thing; I just want to set expectations.

Let's table this for now until we figure out what we need to do to support half-height rack units (#51) and go from there. Maybe we can knock them out at the same time.

@jeremystretch commented on GitHub (Apr 7, 2021): I don't see a way to implement this idea without completely overhauling the way we currently model rack units. Which isn't to say that would necessarily be a bad thing; I just want to set expectations. Let's table this for now until we figure out what we need to do to support half-height rack units (#51) and go from there. Maybe we can knock them out at the same time.
adam commented 2025-12-29 18:37:48 +01:00
Author
Owner
Copy Link

@Profecy commented on GitHub (Jul 19, 2021):

I would like to second this, since we use PDUs mounted vertically that span about 42U in the rear of the rack.
See those badboys here: https://www.raritan.com/product-selector/pdu-detail/px3-1966v
So far I have implemented them as "unracked" devices.

@Profecy commented on GitHub (Jul 19, 2021): I would like to second this, since we use PDUs mounted vertically that span about 42U in the rear of the rack. See those badboys here: https://www.raritan.com/product-selector/pdu-detail/px3-1966v So far I have implemented them as "unracked" devices.
adam commented 2025-12-29 18:37:48 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Feb 25, 2022):

So far I have implemented them as "unracked" devices.

I do the same here. Although it would be nice, I don't think that 0U devices needs to be represented on the rack elevation. The effort to add this will not match the gain. As long there's a relationship between the 0U device (like a vertical powerbar) and the rack itself, it's OK... at least for us!

My understanding from the original request is more to have a sidecar-type rack in a rack in a parent-child relationship. This should be easier to implement. As for rack elevations, would it need to be displayed vertically? Simply adding small 2-3U racks (represented horizontally) in a column next to the elevation, or even in a separate page would be enough?

@AnythingOverIP commented on GitHub (Feb 25, 2022): > So far I have implemented them as "unracked" devices. I do the same here. Although it would be nice, I don't think that 0U devices _needs_ to be represented on the rack elevation. The effort to add this will not match the gain. As long there's a relationship between the 0U device (like a vertical powerbar) and the rack itself, it's OK... at least for us! My understanding from the original request is more to have a sidecar-type rack in a rack in a parent-child relationship. This should be easier to implement. As for rack elevations, would it need to be displayed vertically? Simply adding small 2-3U racks (represented horizontally) in a column next to the elevation, or even in a separate page would be enough?
adam commented 2025-12-29 18:37:48 +01:00
Author
Owner
Copy Link

@kirk444 commented on GitHub (Feb 25, 2022):

I think the "sidecar-type" rack representation would certainly work for my particular use-case, and the exact visual representation is not critical, something shown horizontally (despite being physically vertical) would still be a big help in my case.

That said, I don't think it helps the "vertically mounted / 0U PDU" case. It may make sense for a 0U PDU to be tracked differently, as they are not actually mounted in the U-space of the cabinet.

@kirk444 commented on GitHub (Feb 25, 2022): I think the "sidecar-type" rack representation would certainly work for my particular use-case, and the exact visual representation is not critical, something shown horizontally (despite being physically vertical) would still be a big help in my case. That said, I don't think it helps the "vertically mounted / 0U PDU" case. It may make sense for a 0U PDU to be tracked differently, as they are not actually mounted in the U-space of the cabinet.
adam commented 2025-12-29 18:37:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 11, 2022):

As there haven't been any substantial changes to how we model rack units under #51, the technical implementation for this proposal needs to be revisited. Anyone interested is welcome to put forth a detailed implementation plan addressing the necessary changes to the existing data model; otherwise, this cannot move forward.

@jeremystretch commented on GitHub (Aug 11, 2022): As there haven't been any substantial changes to how we model rack units under #51, the technical implementation for this proposal needs to be revisited. Anyone interested is welcome to put forth a detailed implementation plan addressing the necessary changes to the existing data model; otherwise, this cannot move forward.
adam commented 2025-12-29 18:37:49 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 26, 2022):

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 26, 2022): 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 18:37:49 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 26, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Nov 26, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
adam commented 2025-12-29 18:37:49 +01:00
Author
Owner
Copy Link

@seandfeeney commented on GitHub (Feb 4, 2023):

I want to second this request. I work in the EDGE space and we have a lot of devices like an Optiplex 3200 which is a vertical standing device. We currently have 8 vertically racked and stacked 4 in front and 4 in back. Many other EDGE use cases (like gateways used in manufacturing environments) will have non-standard rack positions.

EDGE is a fairly new and growing sector for tech and I imagine there are going to be more and more teams testing these devices in their labs.

Allowing for vertically stacked devices that can be oriented front and back to add another position such as a "depth U" position as well. Obviously, we are using these racks in a non-standard way. However, I think this is going to be a growing problem for many teams going forward.

@seandfeeney commented on GitHub (Feb 4, 2023): I want to second this request. I work in the EDGE space and we have a lot of devices like an Optiplex 3200 which is a vertical standing device. We currently have 8 vertically racked and stacked 4 in front and 4 in back. Many other EDGE use cases (like gateways used in manufacturing environments) will have non-standard rack positions. EDGE is a fairly new and growing sector for tech and I imagine there are going to be more and more teams testing these devices in their labs. Allowing for vertically stacked devices that can be oriented front and back to add another position such as a "depth U" position as well. Obviously, we are using these racks in a non-standard way. However, I think this is going to be a growing problem for many teams going forward.
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 pending closure status: revisions needed 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#4572
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?