-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device Hardware Profiles #15342
Comments
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. |
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)? |
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. |
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. |
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:
My response to this was:
|
@jeremystretch and Team, 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. 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. |
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. |
I understand that this might be complicated.
I'd say stick with the basics?
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. |
This feels like it should/could be a plugin rather than a core Netbox feature. We do this very thing today with a simple plugin that takes inventory items and allows us to build flavors for servers. So you can create a flavor e.g. c1.medium and say it must contain one of these CPU's, at least X amount of RAM, and X number of disks. Devices then have a custom field that links to the flavor object and a background job that runs to map servers without a flavor to a flavor that matches their inventory items. |
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
The text was updated successfully, but these errors were encountered: