Open jameno123 opened 4 months ago
bitcollector1
commented
3 months ago These are all items I already have in NetBox Inventory.
My guess is that you would build your own hardware profile based off of the inventory you have collected for your device.
jameno123
commented
3 months ago This request is to find a way to match machines in bulk based on their hardware profile. Right now with netbox it is very difficult to return a full list of machines matching a specific hardware profile. By utilizing a concept of hardware profiles we can extend device_types to make "pre-defined" hardware configurations.
Currently when you create a device, you have only a "device type" - say an R740. But that machine could have multiple different predefined configurations.
One may have one configuration with:
You may then also have another configuration with say:
The goal is to provide two items:
Basically just like device_types can pre-define inventory, the goal of hardware_profiles would be to "allow different combinations of pre-defined inventory items" to define a specific hardware configuration.
While netbox currently does have "inventory" support. Its very difficult to perform the two goals mentioned above without some pretty extensive api calls and scripting logic.
There are/could-be other possible improvements that could later be extended beyond the basic two goals above like preventing removal of inventory created by an attached hardware profile. That is outside the scope of this initial request as the same limitation currently applies with device type.
jeremystretch
commented
3 months ago Currently when you create a device, you have only a "device type" - say an R740. But that machine could have multiple different predefined configurations.
Why not define a unique device type for each build? Additionally, what would happen if you had a device type designated as a particular build, but a user then modified it to deviate from that build (e.g. by adding/removing components)?
jameno123
commented
2 months ago I would accept it to be just like the device type template and the hardware(components) is(are) only copied at creation for the initial version.
That concept could be extended to possibly "lock" the components that are templated and prohibit them from being removed but I think that goes further than necessary.
To answer your Q: Why not create multiple device types?
Because when you are trying to find all servers of a specific type then you have to say "if device type x, or y, or z, or a, or b, or c".
A hardware profile will allow you to copy specific configurations of the pre-defined "templates of hardware".
Secondly, you could then as long as the original template id is defined in the device model you could search for that "flavor" of the specific device type.
jeremystretch
commented
2 months ago Because when you are trying to find all servers of a specific type then you have to say "if device type x, or y, or z, or a, or b, or c".
Yes, and that's a very reasonable approach. I don't understand why you wouldn't do it this way. If you need some other attribute to track related models, you could introduce a custom field for "series."
You also did not address my second question above.
jameno123
commented
2 months ago Yes, and that's a very reasonable approach. I don't understand why you wouldn't do it this way. If you need some other attribute to track related models, you could introduce a custom field for "series." I would strongly disagree with this.
We would like to keep a single device type referring to a single specific "model" of a server/hardware -- not a specific build or set of components. The device type is "Dell R740" or "Dell R740xd" which is attributed to a specific model type.
Within each of these, we have potentially some 30 different configurations. We are integrated very tightly with many external systems which expect to model things this way such a service now CMDB and having to map 30 different device types in netbox to 1 model type in service now and having that integration be able to tell the difference and do that properly is extremely cumbersome. Adding a custom field helped but it really felt backwards and still didnt solve the need to re-map the data when we exported into servicenow or other asset systems.
I believe I answered both questions in my response, albeit, in reverse order... I am sorry if I have missed something.
I am understanding your second question to be:
Additionally, what would happen if you had a device type designated as a particular build, but a user then modified it to deviate from that build (e.g. by adding/removing components)?
My response to this was:
I would accept it to be just like the device type template and the hardware(components) is(are) only copied at creation for the initial version.
That concept could be extended to possibly "lock" the components that are templated and prohibit them from being removed but I think that goes further than necessary.
rc-networks
commented
1 month ago @jeremystretch and Team, Forgive me for joining uninvited, but I'm looking for something similar too.
It might be nice if you can provide an example here and on the netbox dev demo as to what you think the Netbox - DCIM should look like for Baremetal Servers.
It would also be very nice to see how much CPU, RAM, STORAGE etc. is available (or left, or is not assigned to anything) in a Datacenter/Site in one glance.
Maybe add a feature that would show the Utilization of these units similar to the Utilization of Prefixes? and see where the server(s) with these units are assigned or just hanging there taking up Rack space.
That kind of feature would be helpful if you're looking for a baremetal server resources that you can free up and use somewhere else in the DC. What do you think?
alehaa
commented
1 month ago I think this issue is really complicated. First of all, not all users of NetBox would need this use case, as someone might only document switches and patch panels. So we have to make sure that this feature brings a benefit for hardware management without bothering others who do not use it, e.g. by introducing 60 additional device fields.
Then there is the problem of defining what is really needed, and that can be different for different people. Someone might just want to know what CPU and total memory is installed and could store that in a custom field. Others might want to store each hard drive as a separate item for inventory purposes.
For now, I could see putting this logic into a new plugin or perhaps adding it to NetBox to be consistent with VMs. The plugin could add additional tabs to a device to manage memory, RAM, CPUs. As with interfaces, these tabs would be hidden when no resources have been added, so the UI wouldn't be cluttered. A panel on the main device view could then summarize this data.
rc-networks
commented
1 month ago I think this issue is really complicated. First of all, not all users of NetBox would need this use case, as someone might only document switches and patch panels. So we have to make sure that this feature brings a benefit for hardware management without bothering others who do not use it, e.g. by introducing 60 additional device fields.
I understand that this might be complicated.
Yes, there might still be teams that are still siloed to Network Only roles, but isn't that in the minority these days?
Plus, we call the tool DCIM.
Other teams who own's their own physical server should be able to put their resources in here too, then It can be called the Single source of truth for everyone involved in the DC/site management.
Then there is the problem of defining what is really needed, and that can be different for different people. Someone might just want to know what CPU and total memory is installed and could store that in a custom field. Others might want to store each hard drive as a separate item for inventory purposes.
I'd say stick with the basics?
For example this image that I found on google.
adding it to NetBox to be consistent with VMs
I am actually surprise that we have these fields on VMs but not on Physical servers.
For now, I would be great if someone in the team provide an official example on how to deal with this in the current version. I don't want the management to back down on getting enterprise support just because this feature is missing.
NetBox version
v3.7.3
Feature type
New functionality
Proposed functionality
The ability to define a "hardware profile" much like a device module but at a more generic level that would apply much like a device type.
A hardware profile would include and define inventory items, such as:
Use case
The idea and goal would be to be able to filter devices based on a "hardware profile" so that an automation system can find an available machine to provision (ie: group devices by their hardware capabilities).
My vision would be that much like a device type, you could apply a hardware "profile" to a machine so that all machines with a specific profile would have the same type of hardware.
For example: We routinely have 3-4 different combinations of hardware available ("generations") - though they are all the same device type model.
We could have a Dell PowerEdge 740 with say a Xeon GOLD or a Xeon Platinum CPU in them
Currently - If I want to find all my servers that have the XEON GOLD with 384GB of ram in them it is extremely difficult.
We currently use TAGS and other means to get around it but find that keeping the documentation up to date and the "unterstanding" of tag X means Y to be very difficult. Having a "hardware profile" attached to a server would allow me to query (and) identify my common hardware.
Hardware Profile #1 (entirely made up, ignore the spec ref):
Hardware Profile #2:
Using the ability to define the hardware and then apply it to a device would allow me to search for all devices matching hardware profile id = 1 or = 2.
This would greatly ease the ability of provisioning systems to find hardware without extensive searching of the hardware inventory as we routinely say "service of type x, run on hardware of type y" where x is the serv(ice) and y is the hardware profile.
Database changes
External dependencies
No response