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.

[bluikko]

Thank you for the detailed reply. I am happy to expand on my OP and hear more about the feature!

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.

Could be but this is an implementation detail in my opinion.
My automation builds the Inventory items hierarchy out of a few different outputs from servers, such as Redfish and different CLI utilities. For example it adds as Inventory items all RAM slots whether empty of populated and those slots that are populated get the data of the DIMM. Empty slots just list the slot name with no data of an installed module. Same for CPU, RAID controller, busses, disk slots etc.
This seems to be a common pattern, I saw screenshots in issues of a similar system but slots were modeled as their own hierarchy level under which installed module was a child item.

So how I have it currently most Inventory items actually represents a bus, slot, etc.

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.

With "not really reflecting the reality" I meant about how that would be modeled.
The Modules and Module bays would be more of a necessary evil forced by the NetBox model rather than some existing physical thing; CPU is a Module that has Module bays for memory channels Modules and memory channels would have Module bays for DIMMs. Logically this might work on some level but would seem a bit counterintuitive.
This example would create some necessary extra Module bays such as a "RAM channel module bay" on the "CPU module", I guess that is not a big problem.

I have not thought about the SAS expander, PCI switch case but I can imagine it would be more of these "logical" modules.

I do think it seems quite complex; right now all I need to do is loop inventory item API.

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.

You are right I have missed an additional screenshot that indeed would have the Label attribute.

I was not aware of "module type profiles". I had looked through the open 2 "Milestones" and open Issues for few latest months or so but I missed it; for reference it seems to be #19002 (closed) and it seems to be useful indeed!

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 need to read #19002 and see what it brings to the table. It does seem mightily more complex and I probably just am not thinking about all the possible benefits since to me the cost/benefit of the added complexity seems negative.

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.

Unfortunately all I can recall is that Inventory items didn't have hierarchy until quite recently. I'll take your word for it.

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.

I will do that. Thank you again for your detailed reply.

[andrejzverev]

@jeremystretch Can you please share your thoughts? We using Inventory Items as simple inventory. On Site we have Location (as warehouse) and Device to which all our ZIPs (SDD/HDD/Memory/SFP/etc) was attached. Since Device allow attach unlimited Inventory Items it's fine. We easy count that we have. In new Modules concept it's not possible to attach to only Device, you need also also select Module bay which have capacity on Device (we can create lots of them in theory, but it's hard to assign every Module to free bay via csv import). For now the idea is only to make a Script that would automatically create a lot these Module Bays at Device and search free bay to assign Module to it.

Of course there are plugins that implements Inventory but for us their functionality is redundant, so we did something like this with 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.