starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-02-26 02:35:12 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Restructure of Devices, Child Devices and Modules #7123

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

Originally created by @cpmills1975 on GitHub (Oct 19, 2022).

NetBox version

v3.3.5

Feature type

Change to existing functionality

Proposed functionality

(This is potentially controversial but I wanted to raise it and see where discussion goes)

Modules are scrapped and the functionality that they add is moved to Device

  • Devices will be able to contribute components to a parent device - the component tables will include a column for child device/child device bay instead of module/module bay.
  • Removing child devices from a device removes components contributed to the parent in the same way removing a module does now.
  • Interface names on child devices will be able to be templated with {device_bay} or similar to dynamically name them as modules do at present.

The constraint on device bays having to exist in a 'parent' device is removed.

  • Components of child devices of child devices 'bubble up' to the ultimate parent device - enumeration of components is recursive.
  • Primary IP addresses for a device can be taken from any IP address assigned to any interface on the device or any interface on any (recursive) child device, but an IP address may only be a primary IP address for a single device.

Line cards (currently modules) will be able to exist anywhere a device is currently able to exist, be that inside a parent device, 'unracked' in a rack or in a location (cupboard).

Use case

Modules are effectively passive devices that contribute a number of components to the parent device to which they belong. They are passive in that they are essentially devices (in the generic sense) that can not be managed in their own right and do not have a primary IP address of their own.

Child devices could be considered physically similar to modules in that they sit within a larger 'chassis' type device, but with the important distinction that they can be managed in their own right - i.e. they have primary IP addresses. Child devices do not contribute components to a parent device which from a logical/management perspective makes perfect sense, but from a physical perspective does not (is an interface on a switch in a blade center a port of that switch or a port on the chassis? Logically part of the switch, but physically they appear to be part of the chassis).

#10500 asks for modules to be able to accommodate sub modules and it struck me that devices can already contain child devices albeit child devices cannot contain device bays.

I can't remember where I've seen it, but there was a request to have modules exist outside of devices. I get that NetBox isn't an Asset Management tool, but modules do from time to time exist in cupboards (albeit temporarily) and this was solved for devices by allowing Device to exist in a Location outside of a rack. NetBox is a much more accessible tool for engineers than asset management tools which are typically aimed at an organisation's bean-counters!

Some fields available to a device don't make sense in the context of child devices/modules - vc_position etc. However there is a precedent here - wireless attributes don't really make sense to a 1000Base-T ethernet port - we simply ignore them!

The functionality of modules is comparatively light at present - it appears to be a much cut down device with some functionality to adopt existing components and a couple of foreign keys that tie it to a module bay. If the functionality is to be moved in to a device, now is a good time to do it before too many additional feature requests for modules are raised.

Database changes

The Module model will disappear and migrations would be required to convert existing Modules to Devices
ModuleBays would disappear and be replaced with DeviceBays.

External dependencies

None

Originally created by @cpmills1975 on GitHub (Oct 19, 2022). ### NetBox version v3.3.5 ### Feature type Change to existing functionality ### Proposed functionality (This is potentially controversial but I wanted to raise it and see where discussion goes) Modules are scrapped and the functionality that they add is moved to Device - Devices will be able to contribute components to a parent device - the component tables will include a column for child device/child device bay instead of module/module bay. - Removing child devices from a device removes components contributed to the parent in the same way removing a module does now. - Interface names on child devices will be able to be templated with {device_bay} or similar to dynamically name them as modules do at present. The constraint on device bays having to exist in a 'parent' device is removed. - Components of child devices of child devices 'bubble up' to the ultimate parent device - enumeration of components is recursive. - Primary IP addresses for a device can be taken from any IP address assigned to any interface on the device or any interface on any (recursive) child device, but an IP address may only be a primary IP address for a single device. Line cards (currently modules) will be able to exist anywhere a device is currently able to exist, be that inside a parent device, 'unracked' in a rack or in a location (cupboard). ### Use case Modules are effectively passive devices that contribute a number of components to the parent device to which they belong. They are passive in that they are essentially devices (in the generic sense) that can not be managed in their own right and do not have a primary IP address of their own. Child devices could be considered physically similar to modules in that they sit within a larger 'chassis' type device, but with the important distinction that they can be managed in their own right - i.e. they have primary IP addresses. Child devices do not contribute components to a parent device which from a logical/management perspective makes perfect sense, but from a physical perspective does not (is an interface on a switch in a blade center a port of that switch or a port on the chassis? Logically part of the switch, but physically they appear to be part of the chassis). #10500 asks for modules to be able to accommodate sub modules and it struck me that devices can already contain child devices albeit child devices cannot contain device bays. I can't remember where I've seen it, but there was a request to have modules exist outside of devices. I get that NetBox isn't an Asset Management tool, but modules do from time to time exist in cupboards (albeit temporarily) and this was solved for devices by allowing Device to exist in a Location outside of a rack. NetBox is a much more accessible tool for engineers than asset management tools which are typically aimed at an organisation's bean-counters! Some fields available to a device don't make sense in the context of child devices/modules - vc_position etc. However there is a precedent here - wireless attributes don't really make sense to a 1000Base-T ethernet port - we simply ignore them! The functionality of modules is comparatively light at present - it appears to be a much cut down device with some functionality to adopt existing components and a couple of foreign keys that tie it to a module bay. If the functionality is to be moved in to a device, now is a good time to do it before too many additional feature requests for modules are raised. ### Database changes The Module model will disappear and migrations would be required to convert existing Modules to Devices ModuleBays would disappear and be replaced with DeviceBays. ### External dependencies None
adam added the type: featurepending closure labels 2025-12-29 20:19:28 +01:00
adam closed this issue 2025-12-29 20:19:28 +01:00
adam commented 2025-12-29 20:19:29 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 19, 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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 19, 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:19:30 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 18, 2023):

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 (Jan 18, 2023): 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 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#7123
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?