Skip to content
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

Open
jameno123 opened this issue Mar 4, 2024 · 10 comments
Open

Device Hardware Profiles #15342

jameno123 opened this issue Mar 4, 2024 · 10 comments
Labels
complexity: high Expected to require a large amont of time and effort to implement relative to other tasks netbox status: backlog Awaiting selection for work type: feature Introduction of new functionality to the application

Comments

@jameno123
Copy link

jameno123 commented Mar 4, 2024

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:

  • CPU (mfg, mhz, core count, model, etc)
  • MEM (speed, individual # chips, etc)
  • NIC interface cards (etc)
  • Possibly PSU

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

  • Device Type: Dell R740
  • CPU: 2x Xeon Gold 24 core @ 3.02Ghz
  • MEM: 512GB DDR4 RAM @ 3200Mhz [16x 32GB chips]

Hardware Profile #2:

  • Device Type Dell R740
  • CPU 2x Xeon Platinum 32 core @ 2.5Ghz
  • MEM: 1024GB DDR4 RAM @ 3200Mhz [16x 64GBchips]

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

  • New table device_hardwareprofile - with references to inventory items to clone upon instantiation
  • New reference in device model to map device_hardwareprofile.id

External dependencies

No response

@jameno123 jameno123 added the type: feature Introduction of new functionality to the application label Mar 4, 2024
@bitcollector1
Copy link

bitcollector1 commented Mar 13, 2024

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.

Screenshot 2024-03-13 at 10 57 50

@jameno123
Copy link
Author

jameno123 commented Mar 14, 2024

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:

  • 384GB of ram with 6x64GB chips
  • 2 CPUs with 88 cores
  • 6x 16TB SAS HDDs

You may then also have another configuration with say:

  • 192GB of ram with 6x32GB chips
  • 2 CPUs with 64 cores
  • 2x 960GB SSDs

The goal is to provide two items:

  1. To be able to query and find all machines match a specific hardware profile - give me all machines matching the 384GB/88-core configuration above
  2. To be able to easily create instances of the above configurations quickly

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 jeremystretch added the status: needs triage This issue is awaiting triage by a maintainer label Mar 26, 2024
@jeremystretch
Copy link
Member

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

@jeremystretch jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation and removed status: needs triage This issue is awaiting triage by a maintainer labels Apr 3, 2024
@jameno123
Copy link
Author

jameno123 commented Apr 21, 2024

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
Copy link
Member

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
Copy link
Author

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
Copy link

rc-networks commented May 16, 2024

@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
Copy link
Contributor

alehaa commented May 18, 2024

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
Copy link

rc-networks commented May 20, 2024

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

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.

@jeremystretch jeremystretch added complexity: high Expected to require a large amont of time and effort to implement relative to other tasks status: backlog Awaiting selection for work and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels May 21, 2024
@jasonyates-thg
Copy link

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.

@jeremystretch jeremystretch added the netbox label Nov 1, 2024 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: high Expected to require a large amont of time and effort to implement relative to other tasks netbox status: backlog Awaiting selection for work type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

6 participants