Restructure of Devices, Child Devices and Modules

[cpmills1975]

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

[github-actions]

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]

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.