Nested Child Devices/violating parent-child relationship?

[tomwoodcraft]

The parent/child relationship gives up a max depth of 2 in our device hierarchy. We're looking for 4/5 total depth. Inventory wouldn't work for our use case as we need Cables to hang off of the child most device. What would be the best way of modelling this? Originally the plan was to develop a plugin but since it's part of the core functionality I don't believe this would work. Short of modifying core models (which we wanted to avoid for future update complications), is there something we're missing? Functionality wise or reasons why this is a bad idea? I'm presuming there is good reason for this enforcement but still lacking an overall understanding. Any input/guidance is much appreciated.

[mtinberg]

I think that's not what the Parent/Child relationship is designed to model which is why you are running into such resistance. What are you trying to model? The Parent/Child model is for when independent network devices share rack space, eg. a blade chassis which has distinct Devices with their own management IPs, interfaces, platforms that all plug into a larger unit that is in a rack, or I use it for APC NMC management cards, the SmartUPS is a parent Device and the NMC card is a child Device. It's not used for switch stacks (virtual chassis models that) or for removable line cards that share a management plane on a chassis-based router, those can be inventory items to track the line cards and interfaces all associated with the chassis, not separate devices with their own records. I've also used Parent/Child relationship for NXOS vDC, make the VMs a "child" device as they share a chassis, instead of making the chassis a VM server and documenting the vDCs as VMs. What kind of devices are you modeling that nesting seemed like the best way to solve the problem? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: tomwoodcraft ***@***.***> Sent: Wednesday, January 5, 2022 9:13 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] Nested Child Devices/violating parent-child relationship? (Discussion #8243) The parent/child relationship gives up a max depth of 2 in our device hierarchy. We're looking for 4/5 total depth. Inventory wouldn't work for our use case as we need Cables to hang off of the child most device. What would be the best way of modelling this? Originally the plan was to develop a plugin but since it's part of the core functionality I don't believe this would work. Short of modifying core models (which we wanted to avoid for future update complications), is there something we're missing? Functionality wise or reasons why this is a bad idea? I'm presuming there is good reason for this enforcement but still lacking an overall understanding. Any input/guidance is much appreciated. — Reply to this email directly, view it on GitHub<#8243>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMY3UBNWMG7A4DEFM53UURNZHANCNFSM5LKERUZQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tomwoodcraft]

Thanks for your reply Mark, having read your response and looked more into it, our current vision definitely wasn't right. We were misusing the model as you'd suggested because we wanted more than inventory items offered, it seems to be resolved as part of modules in the 3.2 planned release. -Tom

[DanSheps]

I would wait for the planned 3.2 release which will include modules

[tomwoodcraft]

Thanks to you both, to be clear yes this is purely for dev purposes, trying to play around with the new module and inventory features. Was trying to adjust the foreign key to a generic foreign key to play around with the best so far but haven't managed to get it working yet. Was hoping someone might be able expand on what Jeremy had mentioned on that feature? Will carry on playing around with it

[tomwoodcraft]

Particularly this: "It will also require changing the device_type ForeignKey relationship on the device component template models to a GenericForeignKey, so that they can be associated with ModuleTypes as well."

[candlerb]

Was hoping someone might be able expand on what Jeremy had mentioned on that feature?

Sounds to me like: "this feature hasn't been fully implemented yet, and requires more Python coding to complete"

[tomwoodcraft]

Alright thank you, will carry on working on it myself and keep an eye out for further development

[DanSheps]

@candlerb is correct, you should not be worrying about anything specifically with the internal development. If you want to try it, it should be (somewhat) functional out of the gate.