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

Name of parent device of "Device Bays" in connection #1837

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

Originally created by @uncleVALERA on GitHub (Jul 13, 2018).

Issue type
[X] Feature request
[ ] Bug report
[ ] Documentation

Environment
Python version: 3.5.2
NetBox version: 2.3.5

Description
Interface table has column "Connection". It displays connection device. If it is "Device Bays" than displays only it's name.
Could you make additional column for displaying parent device of "Device Bays"?
Or use same column but split it for both names by slash.

Originally created by @uncleVALERA on GitHub (Jul 13, 2018). **Issue type** [X] Feature request [ ] Bug report [ ] Documentation **Environment** Python version: 3.5.2 NetBox version: 2.3.5 **Description** Interface table has column "Connection". It displays connection device. If it is "Device Bays" than displays only it's name. Could you make additional column for displaying parent device of "Device Bays"? Or use same column but split it for both names by slash.
adam closed this issue 2025-12-29 17:19:38 +01:00
adam commented 2025-12-29 17:19:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 20, 2018):

I don't think the interfaces table is an appropriate place for this. The connected device is a link; one click will get you all that information.

Edit: It would also require additional recursive hits to the database. Definitely not worth the expense given the primary purpose of the view.

@jeremystretch commented on GitHub (Jul 20, 2018): I don't think the interfaces table is an appropriate place for this. The connected device is a link; one click will get you all that information. Edit: It would also require additional recursive hits to the database. Definitely not worth the expense given the primary purpose of the view.
adam commented 2025-12-29 17:19:39 +01:00
Author
Owner
Copy Link

@uncleVALERA commented on GitHub (Jul 20, 2018):

I'm sorry but i think you didn't understand the issue.
I meant the following...
I have a lot of servers with Infiniband cards. These cards are described as "Device Bays" because it is so convenient for us to do an inventory of the cards.
netbox-bays-1
And if i look on the switch i don't see servers connected to the switch. Only "Device Bays".
netbox-bays-2
Could you make it so that connections show parent device for "Device Bays"?
For example:
netbox-bays-3

@uncleVALERA commented on GitHub (Jul 20, 2018): I'm sorry but i think you didn't understand the issue. I meant the following... I have a lot of servers with Infiniband cards. These cards are described as "Device Bays" because it is so convenient for us to do an inventory of the cards. ![netbox-bays-1](https://user-images.githubusercontent.com/10263472/43021051-f485546e-8c6a-11e8-8347-f507e705752b.png) And if i look on the switch i don't see servers connected to the switch. Only "Device Bays". ![netbox-bays-2](https://user-images.githubusercontent.com/10263472/43021070-01694910-8c6b-11e8-9323-56a9a70eee3d.png) Could you make it so that connections show parent device for "Device Bays"? For example: ![netbox-bays-3](https://user-images.githubusercontent.com/10263472/43021238-8ecd88e8-8c6b-11e8-93a4-51fb5277d225.png)
adam commented 2025-12-29 17:19:39 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jul 23, 2018):

I have a lot of servers with Infiniband cards. These cards are described as "Device Bays" because it is so convenient for us to do an inventory of the cards.

That's the wrong way to use Device Bays in Netbox - although I completely understand where you're coming from, because I also thought at first that was the way to do it. It took me a while to "get" how Netbox expects you to work.

Netbox does not model devices with interface cards. It does not even model chassis routers/switches with modular line cards, in the way that you might expect. The documentation could probably be clearer on this point, and it would be really nice to have a modular line card as a new feature (#824) - but it doesn't exist in Netbox today.

What you should do is create interfaces directly on the Device. Then you can use "Inventory Items" to record the type and serial number of the network cards / line cards, if you wish. However there is no direct relationship between specific interfaces and a specific inventory item.

The purpose of the "device bays" feature is to model completely independent devices which are located inside the same rackmount housing: that means basically just blade servers, nothing else. Each of these blades is a "device" in its own right: it has its own management IP address, and its own interfaces, and its own platform (operating system). These interfaces are completely independent from the parent - the parent is nothing more than a housing. Its interfaces belong to the child, not extend the parent. A child device is just like any other independent device, apart from the fact that it physically slots into a blade chassis, rather than fitting directly into a U position in a rack.

So in your particular case:

  • On Server01, add interfaces called ib00 and ib01, set them to type Infiniband
  • On Server01, optionally add an inventory item for the Infiniband card (if you want to track it as a distinct asset)
  • Make a connection from Server01 port ib00 to the relevant switch port

When you browse the switch ports, you'll see a port connected to Server 01 port ib00, just as you wanted.

Don't add any child devices to Server01 - although of course if Server01 itself is a blade, then it would be a child of the blade chassis.

In the case of a modular chassis switch: you'd create a switch device with no device bays. When you want to add a line card, you add interfaces called (say) Gi1/1 to Gi1/24 directly onto the switch; and you also add an inventory item to record the line card asset. With the next line card, you'd add interfaces Gi2/1 to Gi2/24, or whatever, and another inventory item.

The line cards are not "child devices" in "device bays"; rather, all the interfaces are attached directly to the device. When you start doing things like LAGs across line cards, you'll see why this is the necessary approach.

@candlerb commented on GitHub (Jul 23, 2018): > I have a lot of servers with Infiniband cards. These cards are described as "Device Bays" because it is so convenient for us to do an inventory of the cards. That's the wrong way to use Device Bays in Netbox - although I completely understand where you're coming from, because I also thought at first that was the way to do it. It took me a while to "get" how Netbox expects you to work. Netbox does not model devices with interface cards. It does not even model chassis routers/switches with modular line cards, in the way that you might expect. The documentation could probably be clearer on this point, and it would be really nice to have a modular line card as a new feature (#824) - but it doesn't exist in Netbox today. What you should do is create interfaces directly on the Device. Then you can use "Inventory Items" to record the type and serial number of the network cards / line cards, if you wish. However there is no direct relationship between specific interfaces and a specific inventory item. The purpose of the "device bays" feature is to model completely *independent* devices which are located inside the same rackmount housing: that means basically just blade servers, nothing else. Each of these blades is a "device" in its own right: it has its own management IP address, and its own interfaces, and its own platform (operating system). These interfaces are completely independent from the parent - the parent is nothing more than a housing. Its interfaces belong to the child, not extend the parent. A child device is just like any other independent device, apart from the fact that it physically slots into a blade chassis, rather than fitting directly into a U position in a rack. So in your particular case: * On Server01, add interfaces called ib00 and ib01, set them to type Infiniband * On Server01, optionally add an inventory item for the Infiniband card (if you want to track it as a distinct asset) * Make a connection from Server01 port ib00 to the relevant switch port When you browse the switch ports, you'll see a port connected to Server 01 port ib00, just as you wanted. Don't add any child devices to Server01 - although of course if Server01 itself is a blade, then it would be a child of the blade chassis. ----- In the case of a modular chassis switch: you'd create a switch device with no device bays. When you want to add a line card, you add interfaces called (say) Gi1/1 to Gi1/24 directly onto the switch; and you also add an inventory item to record the line card asset. With the next line card, you'd add interfaces Gi2/1 to Gi2/24, or whatever, and another inventory item. The line cards are not "child devices" in "device bays"; rather, all the interfaces are attached directly to the device. When you start doing things like LAGs across line cards, you'll see why this is the necessary approach.
adam commented 2025-12-29 17:19:39 +01:00
Author
Owner
Copy Link

@uncleVALERA commented on GitHub (Jul 24, 2018):

Hello, @candlerb !

Thank you very much for the detailed response!
I really chose not the best way to describe IB-cards, and I agree with the solution you provided.

@uncleVALERA commented on GitHub (Jul 24, 2018): Hello, @candlerb ! Thank you very much for the detailed response! I really chose not the best way to describe IB-cards, and I agree with the solution you provided.
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
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#1837
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?