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

Support for half-u devices #6463

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

Originally created by @CallumS38 on GitHub (May 9, 2022).

NetBox version

v3.2.2

Feature type

New functionality

Proposed functionality

This has been requested before, however the previous issues raised had no practical examples.

Support is needed for half-u devices that do not sit under a parent device, e.g. a chassis

An example of this is the https://network.nvidia.com/pdf/prod_eth_switches/PB_SN2010.pdf which is a half-u device that is independent of the other in the same U, at the minute there's no good way to document these in Netbox without creating a parent "shelf" device with bays which isn't very clear

Use case

For half-u devices such as https://network.nvidia.com/pdf/prod_eth_switches/PB_SN2010.pdf which are independent of each other within the same U

Database changes

I believe this will require an additional option when creating the U size for a model (0.5?)

External dependencies

N/A

Originally created by @CallumS38 on GitHub (May 9, 2022). ### NetBox version v3.2.2 ### Feature type New functionality ### Proposed functionality This has been requested before, however the previous issues raised had no practical examples. Support is needed for half-u devices that do not sit under a parent device, e.g. a chassis An example of this is the https://network.nvidia.com/pdf/prod_eth_switches/PB_SN2010.pdf which is a half-u device that is independent of the other in the same U, at the minute there's no good way to document these in Netbox without creating a parent "shelf" device with bays which isn't very clear ### Use case For half-u devices such as https://network.nvidia.com/pdf/prod_eth_switches/PB_SN2010.pdf which are independent of each other within the same U ### Database changes I believe this will require an additional option when creating the U size for a model (0.5?) ### External dependencies N/A
adam added the type: feature label 2025-12-29 19:41:00 +01:00
adam closed this issue 2025-12-29 19:41:00 +01:00
adam commented 2025-12-29 19:41:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 9, 2022):

Every time this comes up, I have to point out that such devices rely on a parent chassis for installation. In this particular case, the part number (per your data sheet) is MTEF-KIT-D. You need to create this as a rack-mounted device with two device bays, into which the child devices can be installed. This approach is the only way to accurately reflect the real-world physical installation.

@jeremystretch commented on GitHub (May 9, 2022): Every time this comes up, I have to point out that such devices rely on a parent chassis for installation. In this particular case, the part number (per your data sheet) is MTEF-KIT-D. You need to create this as a rack-mounted device with two device bays, into which the child devices can be installed. This approach is the only way to accurately reflect the real-world physical installation.
adam commented 2025-12-29 19:41:01 +01:00
Author
Owner
Copy Link

@CallumS38 commented on GitHub (May 9, 2022):

Fair point, although I believe the "issue" (And why this is raised fairly frequently) is that there is no visual representation based on the rack diagrams that the device is sat on that chassis.

Keeping with the Mellanox example, if I had 8x MTEF-KIT-D with a total of 16 individual switches in a rack, from the Front/Rear rack diagrams you can only see where the chassis/shelf itself lives rather than the devices inside it without further digging down, which means there's no real way to have rack diagrams for these types of devices.

Anyway, it's your call at the end of the day, if using chassis with bays is the intended functionality then we will do that.
Thanks very much!

@CallumS38 commented on GitHub (May 9, 2022): Fair point, although I believe the "issue" (And why this is raised fairly frequently) is that there is no visual representation based on the rack diagrams that the device is sat on that chassis. Keeping with the Mellanox example, if I had 8x MTEF-KIT-D with a total of 16 individual switches in a rack, from the Front/Rear rack diagrams you can only see where the chassis/shelf itself lives rather than the devices inside it without further digging down, which means there's no real way to have rack diagrams for these types of devices. Anyway, it's your call at the end of the day, if using chassis with bays is the intended functionality then we will do that. Thanks very much!
adam commented 2025-12-29 19:41:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 9, 2022):

I believe the "issue" is that there is no visual representation based on the rack diagrams that the device is sat on that chassis.

This is wholly independent from the data model though and could be entertained in a separate FR: It has been proposed in #1911 (and likely others) but was not tenable at that time. Granted that was before we made the change to rendering elevations in SVG, but still there are practical constraints to drawing child devices in rack elevations as space to convey meaningful information is quite limited.

@jeremystretch commented on GitHub (May 9, 2022): > I believe the "issue" is that there is no visual representation based on the rack diagrams that the device is sat on that chassis. This is wholly independent from the data model though and could be entertained in a separate FR: It has been proposed in #1911 (and likely others) but was not tenable at that time. Granted that was before we made the change to rendering elevations in SVG, but still there are practical constraints to drawing child devices in rack elevations as space to convey meaningful information is quite limited.
adam commented 2025-12-29 19:41:02 +01:00
Author
Owner
Copy Link

@CallumS38 commented on GitHub (May 9, 2022):

Fair enough, didn't realise there was a fairly extensive FR for it already. Agreed that it wouldn't look right if the hostname was truncated, and having to add anything dynamic (like pop-out boxes when hovering over the device) basically defeats the point of the rack map and being able to export it anyway. Thanks for taking the time to explain it!

@CallumS38 commented on GitHub (May 9, 2022): Fair enough, didn't realise there was a fairly extensive FR for it already. Agreed that it wouldn't look right if the hostname was truncated, and having to add anything dynamic (like pop-out boxes when hovering over the device) basically defeats the point of the rack map and being able to export it anyway. Thanks for taking the time to explain it!
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 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#6463
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?