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

Two-post rack front/rear faces and half-depth devices #5719

New Issue
Closed
opened 2025-12-29 19:31:49 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:31:49 +01:00
Owner
Copy Link

Originally created by @rbahm on GitHub (Dec 1, 2021).

NetBox version

v3.0.8

Feature type

Change to existing functionality

Proposed functionality

Add an option to the "Rack" object called "Devices consume both front and rear face of rack." When this option is applied, all devices are treated as if the "full-depth" box was checked on the Device Type page - that is to say, the rack elevations show the front and rear of the device, and it is not possible to choose that specific rack position on either face.

Use case

Two-post racks support devices, and do have a front and rear, but devices of any depth are typically going to prevent racking devices on both faces of the rack. However, Netbox is unable to model this accurately - instead, users may be led to believe there is free space on a rack which is not available. Simply inputting all device types as "Full-Depth" isn't a viable solution, since the same Device Types may also be used in 4-post racks where the Full-Depth designation is important.

Database changes

A new column would need to be added to support the proposed flag in the rack object.

External dependencies

No response

Originally created by @rbahm on GitHub (Dec 1, 2021). ### NetBox version v3.0.8 ### Feature type Change to existing functionality ### Proposed functionality Add an option to the "Rack" object called "Devices consume both front and rear face of rack." When this option is applied, all devices are treated as if the "full-depth" box was checked on the Device Type page - that is to say, the rack elevations show the front and rear of the device, and it is not possible to choose that specific rack position on either face. ### Use case Two-post racks support devices, and do have a front and rear, but devices of any depth are typically going to prevent racking devices on both faces of the rack. However, Netbox is unable to model this accurately - instead, users may be led to believe there is free space on a rack which is not available. Simply inputting all device types as "Full-Depth" isn't a viable solution, since the same Device Types may also be used in 4-post racks where the Full-Depth designation is important. ### Database changes A new column would need to be added to support the proposed flag in the rack object. ### External dependencies _No response_
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 19:31:49 +01:00
adam closed this issue 2025-12-29 19:31:50 +01:00
adam commented 2025-12-29 19:31:50 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Dec 3, 2021):

Couldn't that "restriction/behavior" simply be bound to the type field of the created Rack object ?

@jsenecal commented on GitHub (Dec 3, 2021): Couldn't that "restriction/behavior" simply be bound to the `type` field of the created `Rack` object ?
adam commented 2025-12-29 19:31:51 +01:00
Author
Owner
Copy Link

@rbahm commented on GitHub (Dec 3, 2021):

@jsenecal I thought about that as well - it could be configured so any "two-post rack" automatically has this behavior. This eliminates the need for an additional database column. However, this would be a breaking change and might be undesirable for some portion of Netbox users - since I couldn't be sure if some organizations want to be able to model non-full-depth devices on both sides of a two-post rack, adding it as a new column results in the behavior being configurable.

All that said, for my use, making "two-post rack" always mean "devices consume both front and rear face of rack" would be 100% correct all the time. I also can't imagine any scenario where you'd need something else.

@rbahm commented on GitHub (Dec 3, 2021): @jsenecal I thought about that as well - it could be configured so any "two-post rack" automatically has this behavior. This eliminates the need for an additional database column. However, this would be a breaking change and might be undesirable for some portion of Netbox users - since I couldn't be sure if some organizations want to be able to model non-full-depth devices on both sides of a two-post rack, adding it as a new column results in the behavior being configurable. All that said, for my use, making "two-post rack" always mean "devices consume both front and rear face of rack" would be 100% correct all the time. I also can't imagine any scenario where you'd need something else.
adam commented 2025-12-29 19:31:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 8, 2021):

I think it's reasonable to infer this from the rack type.

@jeremystretch commented on GitHub (Dec 8, 2021): I think it's reasonable to infer this from the rack type.
adam commented 2025-12-29 19:31:51 +01:00
Author
Owner
Copy Link

@iunderwood commented on GitHub (Dec 9, 2021):

This is an interesting request, which could be broken into a couple different parts.

  1. An additional field could be added to the rack object to restrict rear mounting. This way, you could still have devices racked on both sides. It's unlikely, but I have seen patch panels mounted on both sides of a two-post rack. Making this restriction based on the rack object could be beneficial for all rack types and not just the 2-posters.

  2. An additional field could be added to the device object to indicate which side is mounted. For example, a terminal server or a horizontal PDU could have images of its front and rear as part of the device type. However, only the "front" is shown as it is mounted, even if the rack ears allow for a rear mount. This would be more beneficial to the visual representation of a given rack, but thought it was worth pointing out here. A two-post rack could show the proper set of front and rear images automatically for all devices if the mounting direction can somehow be pointed out for the object itself.

@iunderwood commented on GitHub (Dec 9, 2021): This is an interesting request, which could be broken into a couple different parts. 1. An additional field could be added to the rack object to restrict rear mounting. This way, you could still have devices racked on both sides. It's unlikely, but I have seen patch panels mounted on both sides of a two-post rack. Making this restriction based on the rack object could be beneficial for all rack types and not just the 2-posters. 2. An additional field could be added to the device object to indicate which side is mounted. For example, a terminal server or a horizontal PDU could have images of its front and rear as part of the device type. However, only the "front" is shown as it is mounted, even if the rack ears allow for a rear mount. This would be more beneficial to the visual representation of a given rack, but thought it was worth pointing out here. A two-post rack could show the proper set of front and rear images automatically for all devices if the mounting direction can somehow be pointed out for the object itself.
adam commented 2025-12-29 19:31:51 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 8, 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. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Feb 8, 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:31:52 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 10, 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 (Mar 10, 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.
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: needs owner 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#5719
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?