-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Description
NetBox version
v4.2.6
Feature type
New functionality
Proposed functionality
Employ a recursive hierarchy (i.e. MPTT) to represent the nested relationships of modules to their parents. Currently, the assignment of child modules to their parents is recorded solely through intermediate relationships in the form of module bays:
flowchart TD
Device --> Bay1(Module Bay 1)
Device --> Bay2(Module Bay 2)
Bay1 --> Module1[Module 1]
Bay2 --> Module2[Module 2]
Module1 --> Bay11(Module Bay 1)
Module1 --> Bay12(Module Bay 2)
Bay11 --> Module11[Module 1]
Bay12 --> Module12[Module 2]
Module11 --> Bay111(Module Bay 1)
Module11 --> Bay112(Module Bay 2)
Bay111 --> Module111[Module 1]
Bay112 --> Module112[Module 2]
With a recursive hierarchy in place on the Module model, the tree can be compressed so that module bay assignment becomes incidental to the arrangement of modules:
flowchart TD
Device -->|Module Bay 1| Module1[Module 1]
Device -->|Module Bay 2| Module2[Module 2]
Module1 -->|Module Bay 1| Module11[Module 1]
Module1 -->|Module Bay 2| Module12[Module 2]
Module11 -->|Module Bay 1| Module111[Module 1]
Module11 -->|Module Bay 2| Module112[Module 2]
This can be achieved by adding a TreeForeignKey named parent to the Module model, similar to what exists on InventoryItem today. We'll need to keep the existing module_bay foreign key on Module in place to retain the parallel relationship to the specific bay in which a module is installed. (The parent and module_bay fields must set together or must both be null.)
Use case
Condensing the hierarchy in this manner will enable us to efficiently render the complete module tree for a given device. Additionally, this work will complement the functionality proposed in FR #19002 to model FRU items as modules.
Database changes
- Add a
parentTreeForeignKey on Module - Apply validation to ensure module bay assignment is consistent with the module hierarchy
External dependencies
N/A