Netbox: Add "Inventory Item Type"

[candlerb]

(Factoring this idea out of #3087)

Environment

• Python version: 3.5.2
• NetBox version: 2.6.1

Proposed Functionality

Add "Inventory Item Type". The relationship would then be Inventory Item -> Inventory Item Type -> Manufacturer. This is analogous to the relationship Device -> Device Type -> Manufacturer.

I propose making this as similar to Device Type as possible. e.g.

• Manufacturer: Seagate
• Model Name: Exos Enterprise 12TB
• (Slug)
• PartID: ST12000NM0007
• Comments: 7200rpm SATA drive

I also propose that the existing "Description" field in Inventory Item would be renamed to "Comments", to be consistent with Device.

Use Case

• Adding lots of similar inventory items - e.g. power supplies, line cards, hard drives, RAM DIMMs. It would avoid copy-pasting part numbers and ensure they are all consistent.
• Easier searching for inventory items - "where are all the hard drives of type XYZ located?"
• Calculating summaries - "how many power supplies of type XYZ do we have installed?" - and validation reports
• As a hook for additional information about a particular inventory item type (e.g. URL to link to documentation, preferred supplier)

Database Changes

• Add dcim_inventory_item_type table, with pointer to dcim_manufacturer
• Unique constraint on (manufacturer, model name)
• Add pointer from dcim_inventory_item to dcim_inventory_item_type.
• Remove the existing nullable link from inventory item to manufacturer
• Rename the "Description" field in inventory item to "Comments"

Note: there will need to be a data migration with automatic creation of inventory item types to support this change. One way to do this would be to automatically create a new inventory item type for each unique combination of "Manufacturer" + "Part ID", using the Part ID for model name as well. If Part ID is null it would have to become model name "Unknown".

(I think it's unlikely that the "Description" field on inventory item has been applied consistently enough to be used as Model Name, but it can be left as "Comments")

Allowing Custom Fields on inventory item types, as they are for device types, would be useful for several different purposes.

External Dependencies

None

Further thoughts

It has been suggested separately that inventory item types should be linked to device types, but I think that's a separate issue and is more complex - it would necessarily be a many-to-many relationship.

It could also be useful to be able to classify inventory item types, e.g. "Hard drive", "RAM", "CPU" etc, making them easier to select. Applying roles to inventory item types, rather than individual inventory items themselves (#3087) might be a way to achieve this. But it could also be done just with a custom field.

[darcynz]

2nd this. Although I would leave the description fields as this relates to an field quite often used specifically by the inventory Item. -> Eg Cisco Line cards.

Custom fields would be good solution and this has been discussed -> #1120.

[jeremystretch]

This seems like it's pushing NetBox too far into asset management territory. Hardware inventory modeling was added with the primary function of allowing the user to locate hardware by serial number. Components were originally intended to be discovered automatically (although that functionality has since been removed).

[thannaske]

Netbox is designed to be a DCIM (yes, also IPAM). In order to properly manage your DC sites you need to track how many and which spare parts you have on-site in order to call remote hands services or to restock your spares. I'm currently looking for a way to achieve this with Netbox and a functionality like this would help.

[darwin67]

This seems like it's pushing NetBox too far into asset management territory. Hardware inventory modeling was added with the primary function of allowing the user to locate hardware by serial number. Components were originally intended to be discovered automatically (although that functionality has since been removed).

That's an interesting statement. If Netbox is supposed to be a DCIM tool, shouldn't asset management be included in the scope as well?

[jeremystretch]

@darwin67 For better or worse, this is where we've drawn the line on scope, a necessary delineation to ensure NetBox remains maintainable. It this does not meet your needs, NetBox may not be the tool for you.

[darwin67]

Fair enough. So if I want asset management and other things that are not considered the core functionalities, I should either fork the repo and extend it myself or wait for #3351 and build a plugin for it then?

[larsli1995]

As @thannaske mentioned.. It would be great to give it the ability to create for example Hard Drives and assign them to a Server. If the Hard Drive will be replaced, it would be great to mark the fault drive as broken, so that we can track all broken and active devices in the future.

[ibivibiv]

First off, hello to everyone... I have been living in the shadows here for quite some time. I would think that in the day to day business of keeping devices alive that you would want to track drift of the assets as they get repaired. Also they can change shape a bit over time. Allowing inventory items to be typed and have lifecycle equal to that of devices is quite sensible in my mind. I do see that the primary "delineation" seems to be around resources and maintenance to keep this application reasonable. If that were to be alleviated and I could provide assistance (more than just myself) to bring such features to the table, would that help relax concerns about bringing inventory items features forward? And when I say resources, I am not talking about a drive by dumping of code. I am talking about active members working the project and keeping that code up to date. I'm looking to see if this is just a philosophical concern or more of a scope and resources concern? We really like this application and want to improve it and maintain its place going forward. If we need to "prove ourselves" we can always do a period of bug fixes and enhancements and then revisit this current set of features to get a comfort level with each other as well. I certainly wouldn't expect anything less given this is my first open contact with all of you. :). Let me know what the thinking is here and lets see where we can take this!

[thannaske]

As far as I understood the main issue with this proposal was that it would be out of scope of netbox. Netbox (aside from the IPAM-functionality) describes itself as DCIM (Datacenter Infrastructure Management) tool. And the reality is that almost everyone that runs some racks in a DC has a storage unit somewhere where drives, RAM or some 3.5"-to-2.5" caddy are stored.

I don't see how this is out of scope. We are fastidiously documenting what is on which height unit and then there is a 3 HE drawer and I just can't keep track of its contents. For me it seems like a clear lack of functionality. I don't have the expectation to track a whole lifecycle for inventory items or server parts, for our personal use case it would be sufficient if we just would know what is current on spare and what not so people don't have to take everything they could possibly need with them, but can look up what's on stock instead. For all the level 1 technicans out there this would be a great benefit and improvement and is clearly in scope of a DCIM imho.

[ibivibiv]

I would think though if you have them live outside the context of the server they reside in then you would want to know their state? As in lifecycle of "in inventory, in use, broken, etc."? Maybe "lifecycle" was a bad choice of words. Status probably is a better one. I would think minimally; typed, statuses, and locality are important at the minimum.

[ibivibiv]

I am thinking these are some decent wire frames of what is involved. I am not sure we'd want to get into the business of "locations" just yet. Site is there, but it does beg the question that if you wanted to say place an inventory item in a holding location that site might not suffice there. Anyway just a quick mockup I did. Apologies for the color oddities (its the tool I'm using)

[ibivibiv]

I also started working up a data domain model of what this might end up being as well.

[ryanmerolle]

v2.8 is coming soon. I would totally be interested in a asset management plugin for spares. Right now I track them via markdown in the comments table of a site.

[ibivibiv]

FYI, both the typing and the role have been implemented in a fork here:

https://github.com/nmereddi/netbox/commit/80943c7ab9e07570be44d5e384917ddc9e04c4e1

If we can get an actual issue up for this and get it accepted we can get this ball rolling? If we are deadlocked then maybe we build out something else in a companion app? I think it would be better to have this functionality built in rather than having to go around it just to track what a component inside a server is and its role?

[skredder]

@ibivibiv Would also be very interested in such a functionality here. Glad to help along and dedicate time and resources for it.
As I don't expect anything like this would be accepted in the main Netbox branch anytime soon, a separate plugin would be the most suitable.

[igloo777]

Hi all)
I created a similar request (for tracking components) in SnipeIT 3 years ago. And this is still not implemented there. I am still getting notifications of SnipeIT users voting to track components. Seems like it highly demanded feature.

[jeremystretch]

Note: there will need to be a data migration with automatic creation of inventory item types to support this change. One way to do this would be to automatically create a new inventory item type for each unique combination of "Manufacturer" + "Part ID", using the Part ID for model name as well. If Part ID is null it would have to become model name "Unknown".

This seems like it would be the biggest impediment to implementing this proposal. Both the manufacturer and part_id fields are optional: How would we automatically migrate to the new model in scenarios where one or both fields may be undefined?

[jeremystretch]

This issue should be considered in conjunction with #824, as there seems to be potential for overlap.

[candlerb]

This seems like it would be the biggest impediment to implementing this proposal. Both the manufacturer and part_id fields are optional: How would we automatically migrate to the new model in scenarios where one or both fields may be undefined?

• In the case that manufacturer is None, the migration would create a fake manufacturer "Unknown" (unless it already exists)
• In the case that the part id is None, the migration would create a fake model "Unknown" under the chosen manufacturer

manuf | part_id | result
-----|-----|-----
foo | bar | manufacturer "foo" model "bar"
foo | None | manufacturer "foo" model "unknown"
None | bar | manufacturer "unknown" model "bar"
None | None | manufacturer "unknown" model "unknown"