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

Add support for children of children #251

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

Originally created by @bdstark on GitHub (Jul 19, 2016).

Child devices should be able to contain other child devices. This is useful in a slot/module situation, where you place a device in a slot, and then modules into that device.

Specifically, the Cisco ASR9010 (and other ASR models) can have a line card that goes into a slot, which then opens two additional slots for modules. In Cisco world:
{chasis|device}/slot/module/port:
A9K-MOD160-TR in slot 0 (0/0/0/0), with A9K-MPA-20X1GE in module 0 (0/0/0/0) and A9K-MPA-8X10GE in module 1 (0/0/1/0)
A9K-MOD160-TR in slot 1 (0/1/0/0), with A9K-MPA-20X1GE in module 0 (0/1/0/0) and A9K-MPA-8X10GE in module 1 (0/1/1/0)

Taking this further, SFPS would fill that last 0 for the interface, and while useful, I think tracking that is beyond this request. It's also covered on the device interfaces, so while a small bit of data is lost (SFP information), the connections can be made.

Originally created by @bdstark on GitHub (Jul 19, 2016). Child devices should be able to contain other child devices. This is useful in a slot/module situation, where you place a device in a slot, and then modules into that device. Specifically, the Cisco ASR9010 (and other ASR models) can have a line card that goes into a slot, which then opens two additional slots for modules. In Cisco world: {chasis|device}/slot/module/port: A9K-MOD160-TR in slot 0 (0/0/0/0), with A9K-MPA-20X1GE in module 0 (0/0/0/0) and A9K-MPA-8X10GE in module 1 (0/0/1/0) A9K-MOD160-TR in slot 1 (0/1/0/0), with A9K-MPA-20X1GE in module 0 (0/1/0/0) and A9K-MPA-8X10GE in module 1 (0/1/1/0) Taking this further, SFPS would fill that last 0 for the interface, and while useful, I think tracking that is beyond this request. It's also covered on the device interfaces, so while a small bit of data is lost (SFP information), the connections can be made.
adam closed this issue 2025-12-29 16:20:08 +01:00
adam commented 2025-12-29 16:20:09 +01:00
Author
Owner
Copy Link

@bdstark commented on GitHub (Jul 19, 2016):

I will add that I created separate devices for each set of unique card/module combinations, so I end up with devices made of three different Cisco P/Ns - the card, and the two modules. This works for my testing, but leads to additional devices.

@bdstark commented on GitHub (Jul 19, 2016): I will add that I created separate devices for each set of unique card/module combinations, so I end up with devices made of three different Cisco P/Ns - the card, and the two modules. This works for my testing, but leads to additional devices.
adam commented 2025-12-29 16:20:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 19, 2016):

Child devices are meant to represent components which have distinct control planes: they can be assigned IP addresses, modules, etc. For example, consider multiple blade servers housed within a common parent chassis.

What you're describing is achieved by defining device modules. These can nest within one another, however the front end currently supports only a single level of manually defined modules.

@jeremystretch commented on GitHub (Jul 19, 2016): Child devices are meant to represent components which have distinct control planes: they can be assigned IP addresses, modules, etc. For example, consider multiple blade servers housed within a common parent chassis. What you're describing is achieved by defining device modules. These can nest within one another, however the front end currently supports only a single level of manually defined modules.
adam commented 2025-12-29 16:20:09 +01:00
Author
Owner
Copy Link

@bdstark commented on GitHub (Jul 19, 2016):

Is this the Device->Inventory tab? These modules don't seem to have interfaces, and are used for things like RAM or CPU? I apologize if I am just not looking in the right place, I have only been testing for a few hours now.

I'm surprised that switch modules would be considered so lightly, compared to a blade server. A switch module adds additional things to the device (ports), which is what I want to track. The documentation for modules indicates "these are used merely for inventory tracking", which is not what I am after.

@bdstark commented on GitHub (Jul 19, 2016): Is this the Device->Inventory tab? These modules don't seem to have interfaces, and are used for things like RAM or CPU? I apologize if I am just not looking in the right place, I have only been testing for a few hours now. I'm surprised that switch modules would be considered so lightly, compared to a blade server. A switch module adds additional things to the device (ports), which is what I want to track. The documentation for modules indicates "these are used merely for inventory tracking", which is not what I am after.
adam commented 2025-12-29 16:20:09 +01:00
Author
Owner
Copy Link

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

This was an intentional design choice early on. Tying interfaces to modules and modules to devices needlessly complicates the data schema and would slow things down quite a bit. You can still convey all the information needed about a modular switch. The interfaces just don't go away automatically when you delete a module.

@jeremystretch commented on GitHub (Jul 20, 2016): This was an intentional design choice early on. Tying interfaces to modules and modules to devices needlessly complicates the data schema and would slow things down quite a bit. You can still convey all the information needed about a modular switch. The interfaces just don't go away automatically when you delete a module.
adam commented 2025-12-29 16:20:10 +01:00
Author
Owner
Copy Link

@bdstark commented on GitHub (Jul 20, 2016):

Thanks for the background - thats helpful.

@bdstark commented on GitHub (Jul 20, 2016): Thanks for the background - thats helpful.
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#251
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?