Inventory Items deprecation and removal -- implications and gaps

[bluikko]

#19004 dropped the bomb that Inventory Items will be marked deprecated for eventual removal.

How could the existing gaps be plugged between Inventory Items and Modules?

It is a bit unclear what exactly is the replacement, the Issue talks about both "models" and "modules". I assume the replacement feature is Module Bays, Module Types and Modules.

At least one very important feature seems to be missing:
Modules do not seem to be well suited for modeling an arbitrary hierarchy. They seem to be intended for a rigid system of modules installed to a corresponding slot/bay.
For example I have a hierarchy of BIOS > CPU > PCI bus > add-on card and BIOS > CPU > Memory channel > DIMM. This is critical for modeling NUMA systems accurately and some (most) of the levels in the hierarchy may have multiple nodes.
If I wanted to recreate this using Modules then I would need to create Module Bays inside Module Types. Which seems fine with the original purpose of Modules being something like a module/line card of a router but would be very cumbersome to implement and not really reflecting the reality in the aforementioned example cases.

Another inconvenience is that it seems Modules are installed in Module Bays but not all Inventory Items might use a "bay".
For example a PCI switch or a SAS expander, both very important information for modeling performance-critical aspects of a high-performance system.

Then let's look at the actual information we can put in the Inventory Item and Module Type + Module models:
There seems to be no replacement for attributes Role and Label.
On the other hand Module adds Comments attribute.

In summary: I am very surprised that such an idea is even floated. Modules are obviously something very different from Inventory Items, a feature that was intended for "module in a slot/bay" that is now being touted as a replacement for any sort of generic item inside a Device.
NetBox seemed to always have a very uncompromising position on "correctness" (see for example #18434) and this Modules as Inventory Items seems to disregard it completely or simply not even consider these possible use cases of Inventory Items.

I wonder what is gained by removing Inventory Items?
Is there an overhead in keeping this feature? It seems very much "feature-complete" and had its latest additions not that long ago which are now being thrown away.

Hopefully a plug-in will eventually bring back the Inventory Items feature as I do not see how a rigid type&bay-based system could ever truly replace Inventory Items.

Inventory Item:

Module Type:

Module:

[jeremystretch]

Modules do not seem to be well suited for modeling an arbitrary hierarchy. They seem to be intended for a rigid system of modules installed to a corresponding slot/bay.

But then

For example I have a hierarchy of BIOS > CPU > PCI bus > add-on card and BIOS > CPU > Memory channel > DIMM.

Those certainly sound like rigid systems of modules installed into corresponding slots/bays. 🙂 In fact, inventory items can't model this hierarchy fully, as it provides no concept of bay/slot/position into which a child item is installed. Hence the migration toward modules.

If I wanted to recreate this using Modules then I would need to create Module Bays inside Module Types. Which seems fine with the original purpose of Modules being something like a module/line card of a router but would be very cumbersome to implement and not really reflecting the reality in the aforementioned example cases.

I'll challenge that. Bays are defined on the module type, and get instantiated automatically. And in what way does it not reflect reality? CPUs are installed into sockets, right? And PCI cards go into numbered slots? It seems perfectly suited for this use case.

There seems to be no replacement for attributes Role and Label.

Module bays have labels and the introduction of module type profiles, which introduce support for fully configurable custom attributes, more than replaces the functionality of inventory item roles IMO.

I wonder what is gained by removing Inventory Items? Is there an overhead in keeping this feature?

We remove a limited feature which has been made completely redundant by the improvements to modules & module types. This establishes a single, clear solution for modeling FRU hardware while removing a substantial amount of redundant functionality from the code base.

I am very surprised that such an idea is even floated. Modules are obviously something very different from Inventory Items, a feature that was intended for "module in a slot/bay" that is now being touted as a replacement for any sort of generic item inside a Device.

They aren't, though, inherently; we've just been using them for different purposes. Recall that modules were introduced after inventory items specifically to address some of the shortcoming of inventory items, namely that it did not provide any context around the parent-child relationship and didn't allow for the creation of reusable components. This is merely the continuation of that evolution.

At any rate, I suggest waiting for the v4.3 beta to experiment with the (mostly) finished product. I suspect that once you spend some time with the new functionality, especially the ability to add custom attributes to module types, you'll agree that these improvements deliver a far more capable solution than inventory items.

[pheus]

hi @andrejzverev,
While I’m not one of the maintainers, I wanted to point you to Feature Request #19003 – Support for offline storage of modules. This looks like it’s aimed exactly at scenarios like yours, where modules (like SFPs, drives, memory, etc.) need to be stored at the Site or Location level, independently of a Device or Module Bay.

Hopefully, this feature will help bridge the gap introduced by the shift to the new Modules model without requiring workarounds like scripting bay creation or relying on plugins with broader scope than you need.

[andrejzverev]

@pheus thanks! Looks like exactly what I need. I hope that this will be implemented.

[pheus]

@andrejzverev Great to hear!
Make sure to give the feature request a 👍 as well - the maintainers often prioritize based on user demand.

[bluikko]

hi @andrejzverev, While I’m not one of the maintainers, I wanted to point you to Feature Request #19003 – Support for offline storage of modules. This looks like it’s aimed exactly at scenarios like yours, where modules (like SFPs, drives, memory, etc.) need to be stored at the Site or Location level, independently of a Device or Module Bay.

Hopefully, this feature will help bridge the gap introduced by the shift to the new Modules model without requiring workarounds like scripting bay creation or relying on plugins with broader scope than you need.

So what you are saying is essentially: "make a new feature that implements a fraction of the functionality of the existing feature that is removed"?

[pheus]

So what you are saying is essentially: "make a new feature that implements a fraction of the functionality of the existing feature that is removed"?

Hi @bluikko,

Not arguing for or against the deprecation - just noting that feature #19003 should cover andrejzverev’s need to store spare modules at site/location level.
I also like to track modules independently of devices, so I support that feature.

[tyler-8]

The use case that I'm looking at is tracking individual SFPs. Today with the inventory setup it's easy; I can track the part number and serial number for each individual SFP, whether it's in a fixed chassis, or in a linecard (module) that goes into a bay. With the Module Type Profiles, it seems like this link isn't possible.

[jeremystretch]

It's certainly possible; in fact, this is one of the primary use cases that informed the implementation of module type profiles.

[tyler-8]

Is this loosely the hierarchy you have in mind for this scenario?

Device > Module Bay > Module (Linecard w/4 ports) > 4x Module Bay > Module > Interface (SFP)