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.

[michaelmcdonald]

@tyler-8:

This is an answer I have been trying to get for some time. My guess is that it wasn't entirely thought out (hence no examples in the Netbox public demo or discussion of it in documentation). This is also why numerous individuals are encountering issues trying to take advantage of the {module} variable when you have module bays instantiated from modules.

For my purposes that is the hierarchy I have been trying / building out. I feel that Netbox is close to having this aspect handled, but there are a few "gotchas" that need to be fixed.

[tyler-8]

I've played with the logic above to define a switch DeviceType with 24 SFP slots, with 24 SFP Modules inserted, and it works well in general - but yes it still requires a fair amount of work to get the interface names correct for each Device instance, even more so if you have multiple Devices in a VirtualChassis.

For other uses cases I haven't tried modeling other things just yet (like cellular modems/SIM cards/Line-cards/etc), but I think I kind of see a way to get there with the model type profiles. Model type profiles almost feel like a different approach to Custom Objects, but I suspect the Custom Objects plugin will scale and perform better.

[LDTips]

I understand the approach and I am starting to use it. One thing I find currently not possible to do, but correct me if I am wrong with my logic:

Assume a device that has a module bay slot (depth level 0), into which an extension module is inserted (depth 1, one dot), and into it a card that provides SFP slots (depth 2, two dots). At these depth 2 slots I insert an SFP module, which only has a single interface of {module}/{module}/{module} So something like this

Now - this works if I want to see only interfaces that have an SFP inserted, but what if I want to see all interfaces even if no SFP is inserted? I could theoretically make the card that provides SFP module slots also provide interfaces, but in such case the interfaces will have the parent as the whole card, and not the SFP. Another option I see it to create "empty" SFP module and insert it into modules of which interfaces I want to see but have no SFP in

The ideas that come to my mind is to create the ports manually, not as a part of a module, and then "adopt" them upon insertion of the SFP, which is a bit cumbersome.

[fzs]

I guess strictly speaking a SFP slot is not an interface? Therefore no interface shows up, because the SFP itself provides the interface, not the slot?

[ein-stein-chen]

I guess strictly speaking a SFP slot is not an interface? Therefore no interface shows up, because the SFP itself provides the interface, not the slot?

If one is working mainly with (simple) DAC/AOC cables I would argue that the SFP slot is an interface as one would directly connect the cable to the SFP slot.

Related question: #19241 (reply in thread)
were the resolution was (#19241 (reply in thread)):

[to just model] each end as if it was a separate transceiver and duplicating the information.

which I think is more of a workaround.