Enable the association of inventory items with device components

[jeremystretch]

NetBox version

v3.0.10

Feature type

New functionality

Proposed functionality

Enable users to associate an inventory item with a particular device component installed within the same parent device. This would be done by adding a GenericForeignKey relationship to the InventoryItem model.

Use case

This would allow users to better model the installation of items such as transceivers or antennas, conveying a relationship to a specific component for each.

Database changes

Add a GenericForeignKey field to the InventoryItem and InventoryItemTemplate models, allowing the associating with device components or component templates respectively.

External dependencies

No response

[hiddenman]

That would be really useful and closes most of the cases, thank you.

[hiddenman]

@jeremystretch Btw, what does "a particular device component installed within the same parent device." mean?
What are components in this case? Any class from device_components.py including Interfaces/Ports?

[jeremystretch]

@hiddenman yes, any of the device component models (except device/module bays).

Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS).

I'll give this some more thought. Interested to see what others think.

[DanSheps]

Why do we want to mess with the parent field? Could we not use a different field to denote what component we use?

[jeremystretch]

We could, but does that make sense? Can an inventory item be a child of both a device component and another inventory item? And if so, would users want to model it as such?

[hiddenman]

Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS).

@jeremystretch Actually, i've never used Parent/Child for InventoryItem just because didn't understand the logic behind them.

In our case we just can't easily store information about our SFP-modules and their ports, splitter cables and their ports and so on.
Nowadays we have to add lots of stupid custom fields to cover common cases.

[jeremystretch]

Actually, i've never used Parent/Child for InventoryItem just because didn't understand the logic behind them.

Here's an example hardware inventory from a Juniper switch:

Item             Version  Part number  Serial number     Description
Chassis                                TB3716XXXXXX      Virtual Chassis
Routing Engine 0          BUILTIN      BUILTIN           QFX Routing Engine
Routing Engine 1          BUILTIN      BUILTIN           QFX Routing Engine
FPC 0            REV 31   650-049941   TB3717XXXXXX      QFX5100-24Q-2P
  CPU                     BUILTIN      BUILTIN           FPC CPU
  PIC 0                   BUILTIN      BUILTIN           24x 40G-QSFP
    Xcvr 0                NON-JNPR     34544000XXXX      QSFP+-40G-CU3M
    Xcvr 1                NON-JNPR     33994000XXXX      UNKNOWN
    Xcvr 2                NON-JNPR     33994000XXXX      UNKNOWN
    Xcvr 3                NON-JNPR     33994000XXXX      UNKNOWN
    Xcvr 4                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 5                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 6                NON-JNPR     34668000XXXX      UNKNOWN
    Xcvr 7                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 8                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 9                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 10               NON-JNPR     34668000XXXX      UNKNOWN
    Xcvr 18               NON-JNPR     A75P02XXXX        UNKNOWN
    Xcvr 19               NON-JNPR     A75P02XXXX        UNKNOWN
    Xcvr 22               NON-JNPR     1615201XXXX       QSFP+-40G-CU1M
    Xcvr 23               NON-JNPR     1615201XXXX       QSFP+-40G-CU1M
  Power Supply 0 REV 04   740-044332   1GA1650XXXX       JPSU-650W-AC-AFI
  Power Supply 1 REV 04   740-044332   1GA1650XXXX       JPSU-650W-AC-AFI
  Fan Tray 0                                             QFX5100 Fan Tray 0, Back to Front Airflow - AFI
  Fan Tray 1                                             QFX5100 Fan Tray 1, Back to Front Airflow - AFI
  Fan Tray 2                                             QFX5100 Fan Tray 2, Back to Front Airflow - AFI
  Fan Tray 3                                             QFX5100 Fan Tray 3, Back to Front Airflow - AFI
  Fan Tray 4                                             QFX5100 Fan Tray 4, Back to Front Airflow - AFI

You can see that the CPU, PIC, power supplies, and fans are all children of the FPC item, and the transceivers are all children of the PIC. The parent field in NetBox is used to track these associations.

[candlerb]

@jeremystretch:

Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS).

I'll give this some more thought. Interested to see what others think.

I'm a bit late to the party here: but I observe that if you're allowing an inventory item to be associated to an existing device component using a generic FK, then you could also allow it to be associated to a (parent) inventory item using the same generic FK relation.

Values in the existing "parent" field can be auto-migrated. In fact, you could still call the association "parent" if you want.

Looking at the merged change, it has added component_type and component_id fields, in addition to retaining "parent". Therefore I'd suggest either:

1. Remove the "parent" field. As part of migration, for any object which currently has "parent" set, copy the parent ID to component_id, and set the component_type to "Inventory Item". Or:
2. Rename "component_type" and "component_id" to "parent_type" and "parent_id", together with the migration described in (1)

The nested inventory item hierarchy will now be modelled as a standard parent-child rather than a nested tree, but I don't really see any problem with that - the hierarchy is never going to be more than 2 or 3 levels deep in practice.

[BrunoBlanes]

Hi there, quick question, would this feature allow me to add an inventory item to a physical interface? We have a very common use case of SFP+ interfaces and transceivers. We don't want them as devices and wouldn't make sense to have them loose on the device. We need it to be part of an interface.

[candlerb]

Yes, a "device component" means an interface, front port, rear port, power port etc.

[BrunoBlanes]

Awesome, to get an early preview of this the only way is to compile the feature branch?

[candlerb]

I don't think you should need to "compile" anything; I believe just git checkout origin/feature and then install as usual (./upgrade.sh) but haven't tested it myself.

Whatever you do, don't do this on your production system or database. Make a copy of your database into a separate machine or VM, and do it there. You will have to throw it away before migrating to the final 3.2 release.

[BrunoBlanes]

We're starting fresh with NetBox, so there's no loss of data, thanks!

[candlerb]

OK, but remember that any data you put into this instance will also be lost. There is no upgrade path from feature branch or any beta release to a production release.

[BrunoBlanes]

Oh, okay. Thanks for the heads-up.

[drmsoffall]

I sincerely apologize if this is "just me" but I really struggled to understand how to use this feature. The docs don't clarify the following:

• Associating an inventory item with a component requires navigating to the component table and using the '+' icon to add a new inventory item
• There is no way to associate an existing inventory item with a component

It's possible I'm not fully grasping the interface yet. In any case, maybe adding some clarifications to the docs would help? Thanks!