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

Visualize chassis (aka parent device) and child devices #7406

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

Originally created by @salvadorb on GitHub (Dec 21, 2022).

NetBox version

v3.4.1

Feature type

Change to existing functionality

Proposed functionality

The proposed functionality add a visual diagram of parent device (in our example a OTN chassis)
In our vendor NMS we can see the visual representation of the slots being used by each child device, but in Netbox we don't have this visual guide, which is important for installers:
image

In our example it's:

  • 3 columns
  • 1st column has only 1 row
  • 2nd column has 9 rows
  • 3rd column has also 9 rows

Here is the example of how many child devices can a parent device have:
image

Additionally, it would be amazing if a child device can use more than 1 slot, like the example of the child device which is using slots 8 and 10, but in Netbox device bay we need to create two separate child devices in order to mark that 2 slots are being used.

Use case

This is extremely helpful for OTN chassis, Router chassis and switch chassis, since installers and planners can have a visual representation of the child devices within a parent device with several slots.

Database changes

No response

External dependencies

No response

Originally created by @salvadorb on GitHub (Dec 21, 2022). ### NetBox version v3.4.1 ### Feature type Change to existing functionality ### Proposed functionality The proposed functionality add a visual diagram of parent device (in our example a OTN chassis) In our vendor NMS we can see the visual representation of the slots being used by each child device, but in Netbox we don't have this visual guide, which is important for installers: <img width="934" alt="image" src="https://user-images.githubusercontent.com/23199382/208981450-8ea80765-67fe-4499-bd38-3401bba104af.png"> In our example it's: - 3 columns - 1st column has only 1 row - 2nd column has 9 rows - 3rd column has also 9 rows Here is the example of how many child devices can a parent device have: <img width="1665" alt="image" src="https://user-images.githubusercontent.com/23199382/208981416-1c9d0746-b64d-4bcd-bb67-4b2eba7b6040.png"> Additionally, it would be amazing if a child device can use more than 1 slot, like the example of the child device which is using slots 8 and 10, but in Netbox device bay we need to create two separate child devices in order to mark that 2 slots are being used. ### Use case This is extremely helpful for OTN chassis, Router chassis and switch chassis, since installers and planners can have a visual representation of the child devices within a parent device with several slots. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featureplugin candidate labels 2025-12-29 20:23:01 +01:00
adam closed this issue 2025-12-29 20:23:01 +01:00
adam commented 2025-12-29 20:23:02 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Jan 7, 2023):

This would be a very cool feature but it seems like it would be very, very complex to implement - a lot of different variables. It is very simple in some vendor-specific NMS (I assume, like your example) where the solution does not need to be generic and it needs to only support a handful of cases (a few different chassis and modules for it) but for a totally generic solution like NetBox it is an absolutely massive amount of work, even to just design a generic solution not to mention implementing it.
To be honest I am not hopeful that anyone would step up for doing such an amount of work and suppose this would be marked as a plug-in candidate.

I believe the first step would be to start adding significantly more detail to how exactly this would work. The proposal as it stands currently is more of a start of a discussion...

For starters:

  • How would the available slots be defined in the 2 dimensions? Would there be some kind of definition for matrix of columns / rows / slot number & size per each by entering some numbers - or would the user first define number of rows + columns and then somehow "draw" how the slots lie in that matrix?
  • How would the visual representation be rendered? Would it render just the installed device textual information in each slot? Or would there be images uploaded per installed device that would be rendered in the representation?
    • Or, massively more work: would each of the devices installed on slots have their own 2-dimensional matrix defined by the user where each of the interfaces, ports, etc would be placed and then each module front plate would be rendered based on that (would there be a library of how different types of connectors look and then those could be placed on the 2d matrix of a front plate) - by the way this would be a cool feature for visualizing front plate of any device!

There would probably be quite significant overlap with the "module bays" feature which is quite similar and would also benefit from this kind of feature. So perhaps keeping that in mind when designing the feature as generic enough to be usable in "module bays" also.

Edit: You may want to just take a screenshot from your NMS and upload it as a device photo...

@bluikko commented on GitHub (Jan 7, 2023): This would be a very cool feature but it seems like it would be **very, very** complex to implement - a lot of different variables. It is very simple in some vendor-specific NMS (I assume, like your example) where the solution does not need to be generic and it needs to only support a handful of cases (a few different chassis and modules for it) but for a totally generic solution like NetBox it is an absolutely massive amount of work, even to just design a generic solution not to mention implementing it. To be honest I am not hopeful that anyone would step up for doing such an amount of work and suppose this would be marked as a plug-in candidate. I believe the first step would be to start adding _significantly_ more detail to how exactly this would work. The proposal as it stands currently is more of a start of a discussion... For starters: - How would the available slots be defined in the 2 dimensions? Would there be some kind of definition for matrix of columns / rows / slot number & size per each by entering some numbers - or would the user first define number of rows + columns and then somehow "draw" how the slots lie in that matrix? - How would the visual representation be rendered? Would it render just the installed device textual information in each slot? Or would there be images uploaded per installed device that would be rendered in the representation? - Or, massively more work: would each of the devices installed on slots have their own 2-dimensional matrix defined by the user where each of the interfaces, ports, etc would be placed and then each module front plate would be rendered based on that (would there be a library of how different types of connectors look and then those could be placed on the 2d matrix of a front plate) - by the way this would be a cool feature for visualizing front plate of _any_ device! There would probably be quite significant overlap with the "module bays" feature which is quite similar and would also benefit from this kind of feature. So perhaps keeping that in mind when designing the feature as generic enough to be usable in "module bays" also. Edit: You may want to just take a screenshot from your NMS and upload it as a device photo...
adam commented 2025-12-29 20:23:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 16, 2023):

As discussed above, the proposed functionality would be too complex for us to accept as an exploratory item in core. However, I encourage you to experiment with what's feasible in a separate plugin. Once you have something working to demonstrate, we can discuss whether it would be feasible to incorporate in the core product.

@jeremystretch commented on GitHub (Mar 16, 2023): As discussed above, the proposed functionality would be too complex for us to accept as an exploratory item in core. However, I encourage you to experiment with what's feasible in a separate plugin. Once you have something working to demonstrate, we can discuss whether it would be feasible to incorporate in the core product.
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 plugin candidate 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#7406
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?