Add &#34;Inventory Item Type&#34; #2729

@darcynz commented on GitHub (Oct 10, 2019):

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.

@darcynz commented on GitHub (Oct 10, 2019): 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.

adam commented

@jeremystretch commented on GitHub (Oct 15, 2019):

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).

@jeremystretch commented on GitHub (Oct 15, 2019): 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).

adam commented

@thannaske commented on GitHub (Nov 12, 2019):

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.

@thannaske commented on GitHub (Nov 12, 2019): 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.

adam commented

@darwin67 commented on GitHub (Dec 17, 2019):

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?

@darwin67 commented on GitHub (Dec 17, 2019): > 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?

adam commented

@jeremystretch commented on GitHub (Dec 17, 2019):

@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.

@jeremystretch commented on GitHub (Dec 17, 2019): @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.

adam commented

@darwin67 commented on GitHub (Dec 17, 2019):

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?

@darwin67 commented on GitHub (Dec 17, 2019): 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?

adam commented

@lndmnn commented on GitHub (Jan 16, 2020):

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.

@lndmnn commented on GitHub (Jan 16, 2020): 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.

adam commented

@ibivibiv commented on GitHub (Feb 11, 2020):

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!

@ibivibiv commented on GitHub (Feb 11, 2020): 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!

adam commented

@thannaske commented on GitHub (Feb 11, 2020):

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.

@thannaske commented on GitHub (Feb 11, 2020): 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.

adam commented

@ibivibiv commented on GitHub (Feb 11, 2020):

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 commented on GitHub (Feb 11, 2020): 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.

adam commented

@ibivibiv commented on GitHub (Feb 14, 2020):

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 commented on GitHub (Feb 14, 2020): 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) ![inventory_items_wireframe](https://user-images.githubusercontent.com/976597/74487126-552ec700-4e84-11ea-81e6-0c78048ef41a.png)

adam commented

@ibivibiv commented on GitHub (Feb 16, 2020):

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

@ibivibiv commented on GitHub (Feb 16, 2020): I also started working up a data domain model of what this might end up being as well. ![domain_diagram](https://user-images.githubusercontent.com/976597/74598864-e21d8000-503e-11ea-8586-1c7fc73e195c.png)

adam commented

@ryanmerolle commented on GitHub (Mar 11, 2020):

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.

@ryanmerolle commented on GitHub (Mar 11, 2020): 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.

adam commented

@ibivibiv commented on GitHub (Apr 10, 2020):

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

80943c7ab9

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?

@ibivibiv commented on GitHub (Apr 10, 2020): 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?

adam commented

@skredder commented on GitHub (Jun 15, 2020):

@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.

@skredder commented on GitHub (Jun 15, 2020): @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](https://netbox.readthedocs.io/en/stable/plugins/) would be the most suitable.

adam commented

@igloo777 commented on GitHub (Nov 20, 2020):

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.

@igloo777 commented on GitHub (Nov 20, 2020): 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.

adam commented

@jeremystretch commented on GitHub (Dec 21, 2020):

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 commented on GitHub (Dec 21, 2020): > 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?

adam commented

@jeremystretch commented on GitHub (Dec 22, 2020):

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

@jeremystretch commented on GitHub (Dec 22, 2020): This issue should be considered in conjunction with #824, as there seems to be potential for overlap.

adam commented

@candlerb commented on GitHub (Dec 22, 2020):

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"

@candlerb commented on GitHub (Dec 22, 2020): > 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"

adam commented

@stale[bot] commented on GitHub (Feb 6, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Feb 6, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented