I'd like to discuss a bit what's the best way to store this data in Netbox, because maybe the custom fields are not the best way.
How will these data be used? How much it will need to be integrated in our current automation efforts?

Some alternatives that came to mind.

Device types

Maybe we could create a custom device type for each configuration and use directly those in netbox? For now we could use the comment field in the device type to add any details we want to identify it, and later on, when we'll be on Netbox 2.11.0+ we could use the config context field (JSON or YAML) to have a bit more structured data there. The use of config context will also allow to retrieve it from any device as those are hierarchical. (see https://netbox.readthedocs.io/en/stable/models/extras/configcontext/ )
As an example I've created https://netbox-next.wikimedia.org/dcim/device-types/135/
We could also consider to have a WMF manufacturer, but it seems an unnecessary indirection.

Tags

We've never started to use tags in Netbox because they are global. That doesn't mean we will never use them. We could consider if this might be a good use case or not. Although I'm not convinced.

Config context

To give an example of config context I've created https://netbox-next.wikimedia.org/extras/config-contexts/1/ (don't look at the format, it's just a quick example I came up without too much thought). It's attached to a tag and not a device type because we are on Netbox 2.10.4 that doesn't support yet config contexes for device types.

I started writing this out and have been going back and forth on what is best. It's not easy.

Separate device types for every config is messy, but it may be the best way to do it. Ideally we'd have something like:

<device_type> + <config_type> = <configuration_for_specific_device>

But there is no simple way to do that I think. If we could attach generic config contexts to devices we could create one for every 'config' listed above, and attach the correct one to each device as needed. The closest to that is to use tags, and as per Volans example attach a config context to each tag. That does the same with the indirection of the tag tying the device instance to config context.

But I am also slightly hesitant to use tags. In my previous job we used Netbox and the tags got insane, every team used them for different things and it was a mess. So we need to tread carefully.

What data is in each of the "configs"? Is it just disk and NIC info? In theory you could also create device bays on the device types, and populate the NICs and disks. But that involves creating device types for each of these, and then a device for every disk, NIC etc. You could also argue the interfaces listed for a given device define the NICs, but some information can't be recorded there (model, vendor, only indirectly may reflect PCI location).

Also excuse my ignorance but what do we want to record with the "fiscal year" field?

++ @faidon, who might be able to provide more feedback on this. I think the main purpose of storing the std hw configs in Netbox though would be to have the ability to easily pull data on the number of servers (of each standard hw configuration) we have in production for any fiscal year. This would help us figure out which servers are interchangeable, what parts they use, etc. Initially, I was thinking of having a single Netbox field that shows something like "FY21-22_Config<X>" with a dropdown of the different configuration options (then "FY22-23_Config<X>" for next year, and so forth), but I think whatever is easiest to implement would be ok. Thanks, Willy

@Volans see below for an example of config A vs config C

Some thoughts:
The "config-FY" set is an abstraction of a list of hardware features, and is not divisible. So for that using 1 field would make more sens to me instead of 2. Unless we need to report on all "config A" across the years or all the config of a given FY, which if I understand correctly is out of scope.

How do we make sure that new stored information doesn't go stale or incorrect?
By stale I mean: is a server hardware config fixed along its lifetime? Can some of those characteristics change? (ag. adding ram)?

Additionally we would need a report of some kind that compare those standard config with what's actually configured on the server (for example PuppetDB).

Where will that "hardware features" <-> "config version" mapping be stored and maintained? Will it be programmatically queryable? (eg. to generate the reports).

Other options worth investigating is to use the "inventory items" feature of Netbox, listing the actual parts and having a higher level abstraction reporting on configuration versions.

In T284614#7147294, @wiki_willy wrote:

++ @faidon, who might be able to provide more feedback on this.

Some background that I think most folks here know, but just to make sure we're all in the same page:

For FY21-22 @wiki_willy and team are trying a model where we collapse a lot of our built-to-order orders into a few standardized ones (while of course allowing for build-to-order exceptions). The goal here is simplicity, economies of scale, deeper discounts, interchangeability of orders, etc. Currently we're looking at 10 configs (A through J) plus 2 variants. While we're still experimenting with the details, we expect this to be something we'll continue to do in the future, and expand in subsequent FYs to both have less non-standardized (i.e. less exceptions), as well as to collapse those 10+2 configs into fewer ones. To get to the configs we have today, DC Ops looked into all kind of different configurations in an effort to find commonalities and collapse into a few configs.

These configs really represent some kind of bigger need (e.g. low CPU/mem/disk, compute-heavy, storage-heavy, balanced) akin to how e.g. a public cloud may describe their configurations. In that sense, future configs will be covering similar needs but may be inevitably different configurations year over year. For example, in FY22-23, our smallest, single core, low mem, redundant disk config (config A) may be an R450 instead of an R440, and have, say, 64GB of RAM instead of 32GB of RAM and small NVMe M.2 disks instead of SATA SSD. Given Dell's generations are on a 3-4 year cycle, we may also have the case, however, where some of the configs do not change year over year (e.g. config A is the same in FY22-23 as it was in FY21-22, but config B changed).

So, looking 5 years into the future, when time comes to refresh a batch of e.g. FY21-22 config A servers, it'd be helpful to know that these were procured (5 years ago) as a standardized config A, rather than trying to piece that together by looking at the inventory of the hardware, or by looking at the tasks one by one. It'd be also useful to be able, over time, to extract statistics of our fleet, that span multiple years, in our future efforts to collapse configurations (e.g. config X costs only $M per server more than config Y, and we have N config Y servers deployed, so standardizing here would cost us N*$M).

So, that's the need/problem statement. With regards to the implementation, my thoughts so far:

• While traditionally Netbox has not been great at keeping information about "groups" of devices together, I think in this case it could work. Custom fields feel the most appropriate to me, but I can see inventory work as well. The alternative that I see would be to keep somewhere separate a procurement task->configuration mapping, but that feels... too error prone (it may also end up being 1:N).
• It's conceivable we may have configs span across multiple years, or even multiple configs within the same year -- so something incremental like "Config A (Gen1)" or "Config A01" may be a better idea?
• Hardware changes (add RAM, add/replace disk, etc.) throughout the server's lifecycle will have to be accompanied by DC Ops changing the config field to "Custom/BTO". This is indeed error-prone, though, and needs further thinking
• Having a proper inventory in Netbox (automatically imported during provisioning perhaps) is something it'd be nice to have at some point, but I think orthogonal to this. It could certainly help with regards to post-processing/auditing through Netbox reports, though!

It's conceivable we may have configs span across multiple years, or even multiple configs within the same year -- so something incremental like "Config A (Gen1)" or "Config A01" may be a better idea?

I think this makes a lot of sense. Effectively what we wish to do is "version" each of the configs, A-J. The year is significant (but maybe not our FY?). So perhaps versioning but using the year as a key part of it might make sense. Like "config_a_202101", "config_a_202102", "config_a_202201" etc? Just a thought.

In terms of how to store it in Netbox I think there are a few options:

Device Type

The "device type" in Netbox may be the best way to do this. So rather than having a single device_type for, say, a Dell R440, we have a device type for "Dell R440 Config A 202101" and so on. Applying config contexts to these types would then make the configuration a piece of structured data, easy to use via API. But given the way the config contexts are rendered by Netbox we could override a specific device, if for instance we do add RAM to a particular instance. Rather than have to create a new "device type" for every exception to the standards. Or we could define a generic "device_type" for each server model, to use for exceptions, which implies the config data will be added to each instance.

Pros:

• Uses Netbox structures natively.
• Allows us to leverage Config Context to define the server configs/versions in a structured way.

Cons:

• May result in a lot of device_types in the system.
• Config Contexts cannot currently be attached to device_types, only in version 2.11+

Tags

If we fear using the device_type will mean we have too many of these (each server variant * each config * number of revisions to that config over years), then we could have a single device type for each server model, and use a tag on each instance to record the config/version. Config context in Netbox can be attached to this tag, to record the details of the config/version.

Pros:

• Reduces the number of device_types
• Allows us to leverage Config Context to define the server configs/versions in a structured way.

Cons:

• Use of tags is not ideal, we cannot enforce constraints on where they can be applied in the system.
• Doesn't give us a "drop down", tag needs to be added manually and needs to be correct.
• Tag is not very prominent in the GUI when looking at a device

Custom Fields

We could use custom fields instead of tags, and achieve something similar. A single custom field could refer to the config type + version, or they could be separate. The down side is the data representing what they means is no longer in Netbox, it's just a label and presumably we've a spreadsheet somewhere defining what that is.

But we could maybe still record that in config contexts, with a naming convention that can be derived from the custom field values. Thus you can get the config context data for a particular device by reading the custom field values and requesting the config_context name that follows.

Pros:

• Probably easier to read custom field than a tag in the GUI.
• We can make it a selection/drop-down menu, i.e. limit the options, whereas tags are free-text.

Cons

• I think they can only be added to a device (instance), rather than a "device_type". So the fields need to be created for every instance of a device when it is created. If this is done manually could be human errors.
• There would be no direct, programmatic link between the custom field and the config context. So the config context data would not be rendered for that device, we would only have a way to infer which one was right based on our own naming convention.

Inventory Items

This is not a bad suggestion, but is somewhat moves away from the concept of having a specific set of "builds" defined (you can add any number of inventory items to a given instance, it's not based on it being "config a YYYY" or whatever). It is also subtly different in ways, listing inventory you may document how many 64GB RAM sticks are in a box, as opposed to the total RAM in the server. Config Context data may allow us more control over how we represent elements. Worth thinking about though, alongside questions such as how to we define what RAM slots are used, what disk ports drives are connected to, what PCI slots NICs are in etc.

Device Type seems the best to me, but I worry maybe we will end up with too many. Be interested to know what @Volans thinks.

After having chatted a bit with Papaul and then Cathal last week I was about to write my thoughts but then I was carried away by other more urgent things. So here I am late to the party in the reply :)

Thanks @cmooney for having summarized our chat so well. I agree with more or less everything. My preference too would be device types too and at most use the tags on the device types in addition as a temporary measure before we upgrade to netbox 2.11.

Device Type seems the best to me, but I worry maybe we will end up with too many. Be interested to know what @Volans thinks.

We have 96 device types right now and we plan to have ~12 "current" custom config or less at any given time. So we would add ~12 device types right now and then going forward I expect them to be refreshed every couple of years on average, and then phased away around the 5y mark.
So doing the math would be 12 now + 12 in 2y + 12 in 4y (and before the 6y mark most of the current ones will be gone) for a total of 36 device types. This without counting that we might be able to reduce those to less than 12 going forward.

It doesn't seem too much to me. Keeping the original name (i.e. PowerEdge r440) in the custom name should also help to find them quickly.

As for the names I agree the relation with the fiscal year might be confusing and we could use either YYYY-MM or YYYY-$progressive-id

@Volans @wiki_willy I added 3 Device types into netbox-next. Please see if this format works or if we want to change it. Thanks

 	PowerEdge R440_config_A-FY21-22 	Dell 	— 	1 		0
	PowerEdge R440_config_B-FY21-22 	Dell 	— 	1 		0
	PowerEdge R440_config_C-FY21-22 	Dell 	— 	1 		0

@Papaul thanks, I would rather use normal spaces in device names, as those are fully supported by netbox and easier to read IMHO.
Also, as suggested above, at least for me, it seems more flexible to use the year-month (21-06 or 2021-06 or similar) of the config as date instead of the fiscal year. And I'd try to add the original model at the end, I guess it will be nicer to have all the A configs close by going forward.
I've added the same ones renamed as the above for comparison:

• Papaul's proposal
• Volans's proposal

I think I like @Volans proposal slightly better, but either can work.

I think it should sort better in time. It's not impossible that in a few years we use someone else instead of Dell, but we still have "config A" so best to start with that, and then the YY and MM. I'd probably leave out the dash and brackets and just use "A 2106 PowerEdge R440". But now I'm really splitting hairs.

Thanks for working on this guys. In my opinion, I think I like Papaul's format a little bit better. But if I were to take the best things I like from both Riccardo and Papaul's format (and Cathal's comment), it would probably look something like this:

ConfigA FY21-22 (PowerEdge 440)
ConfigB FY21-22 (PowerEdge 440)
ConfigC FY21-22 (PowerEdge 440)

With regards to the date format, I think the fiscal year makes more sense, because it looks a little cleaner when I look at it. Also, the month/year format could be confusing when an engineer is entering it in. For example, "21-06" or "2106" might not be apparent as the correct option, when someone is installing the hardware in August 2020. I could see something accidentally selecting "20-06" in this scenario, or in similar cases.

@willy I have a case, let say for example we receive a server on 09-2021 with configA so in Netbox we record that server as ConfigA FY21-22 (PowerEdge 440) then in 12-2021 we received another server with configA but that configA did change from the configA with received on 09-2021.
How are we going to make the difference between the configA we recevied on 09-2021 and the one we received on 12-2021? We can not call both configurations in Netbox ConfigA FY21-22 (PowerEdge 440)

Hey @Papaul - it would be pretty rare for us to change the specs on each config mid-fiscal year. I'm only planning on revising it at the beginning of each fiscal. If something unexpected did happen between Sept and Dec 2021 though, and let's Dell changed their specs mid-year....I was thinking we could add something like "ConfigA-rev2 FY21-22 (PowerEdge 440)" or something similar to whichever format we decide to go with.

@willy thanks for the update .
Now we have 3 formats, we need to decide which one we are going to use so we can enter that in Netbox.
format 1 : PowerEdge R440_config_A-FY21-22
format 2: A 21-06 (PowerEdge R440)
format 3: ConfigA FY21-22 (PowerEdge 440)

Please all vote on the format we are going to use.

Thanks.

In T284614#7176311, @Papaul wrote:

@willy thanks for the update .
Now we have 3 formats, we need to decide which one we are going to use so we can enter that in Netbox.
format 1 : PowerEdge R440_config_A-FY21-22
format 2: A 21-06 (PowerEdge R440)
format 3: ConfigA FY21-22 (PowerEdge 440)

Please all vote on the format we are going to use.

Thanks.

I vote format 3.

On the data imput:
If I understand Faidon's comment correctly, the data is not needed before a server provisioning. And can be derived from PuppetDB (memory, CPU, discs) + Netbox (model, FY, U).
If so it should be set automatically to 1/ prevent extra DCops workload, and 2/ prevent manual inputs mistakes.

If it can't be done, we need *at least* a report that alerts on mismatches.

On where to store the data:

• Is there a tight correlation between the existing Purchase date field and the planned revision (eg. FY) part of the config version? If so maybe it's redundant info?
• Storing 3 information (model, config, revision) in a single field (especially drop down like Device Type) prevents us to filter/search on one of them (eg. "show me all the config A servers"), is that an issue? If so, we might want to separate them into several fields.

In T284614#7177927, @ayounsi wrote:

• Storing 3 information (model, config, revision) in a single field (especially drop down like Device Type) prevents us to filter/search on one of them (eg. "show me all the config A servers"), is that an issue? If so, we might want to separate them into several fields.

To expand on this to make this more clear and avoid misunderstanding. The Netbox UI allow just to filter devices by device types. One can select one or more device types to filter for, but is not possible to search in the device type names from the devices page.
So it would be easy to filter all the A 21-06 (PowerEdge R440) for example, but not for all configs of 21-06 or all config A across all versions.
So, depending on the use cases going forward this might be a small annoyance or a big limitation. As DCOps is the primary user of the Netbox UI and these data, I'd like to get their opinion on this.

On a different note I would also like to bring an additional possible problem.
What will happen when a configuration will change forcefully because of the lack of the same components by the vendor?
@wiki_willy Do we plan to assume that a given configuration means exactly identical servers from the hardware point of view or just logically very similar ones?
So, to make a practical example, if the CPU will change slightly in December because the current one is not sold anymore (or the disks will be slightly larger, etc...) will we still be considering that a Config A from june 2021 or will we then call it a Config A from december 2021?

If the former, then the whole idea of storing the data into Netbox config context doesn't make sense anymore because each host could be slightly different. If the former, we might end up with a large number of configs because they could change more often than expected.
In both cases it affects a bit the implementation.

Unfortunately trying to pack 2 additional dimensions into Netbox data model in its current status without affecting usability is a bit tricky.

Hey Riccardo - for any in-year modifications to the hardware specs, I was thinking of calling it rev1, rev2, etc...so something like "ConfigA-rev1." Initially, I was thinking each rev would represent the same exact config, since spec changes within a fiscal year shouldn't happen very often. But if you think logically similar would be better, we could go with that as well. My preference would be to have all the info (config, fiscal year, server model) in one single field. I think the main benefit here (other than for reporting type stuff), would be having the ability to search in Netbox quickly in finding an interchangeable server. For example, if we need to quickly find a replacement part for an out of warranty server, we could do a Netbox search based on this single field, to find get a list of which decom'd servers have the same config. Or if we ever run into a case where we need to add servers in some type of emergency, we can pull this data from Netbox to easily figure out which ones would qualify. Hope this helps, but let me know and I can hop on during your next office hours as well.

In T284614#7187961, @Volans wrote:

@wiki_willy Do we plan to assume that a given configuration means exactly identical servers from the hardware point of view or just logically very similar ones?
So, to make a practical example, if the CPU will change slightly in December because the current one is not sold anymore (or the disks will be slightly larger, etc...) will we still be considering that a Config A from june 2021 or will we then call it a Config A from december 2021?

In T284614#7188879, @wiki_willy wrote:

Hope this helps, but let me know and I can hop on during your next office hours as well.

I've sent the invitation to both you and Cathal so that we can chat about it and make a final decision.

We did have a meeting yesterday with @wiki_willy and @cmooney and here's the summary of it for context (please correct me if I mis-represented anything):

• It was decided that it's better to keep the standard configurations a more high level concept that represent a certain type of server but not too detailed as to keep track of every single piece of HW change. The latter would require too much effort to check and create new configs all the time a vendor changes slightly any HW component and will make the number of device types explode. So for example if the network card or the processor will slightly change at some point we can still keep it as the same device type, while if the changes are more drastic (RAM amount, # cores, etc..) a new version of the standard config will be created.
• Given the planned effort to consolidate the configurations even more going forward, we decided that to avoid confusion some config can be "orphaned". So for example if config B and config C next year will be merged into one that has similar specs of both, we can have a new version of config B and "orphan" config C. Re-numbering all the other configs to have all consecutive letters was deemed much more confusing.
• SRE I/F will think what kind of metadata, if any, we might want to attach to those device types with a Netbox config context for tooling and automation purposes, as opposed to just get the same data from the hosts via PuppetDB (optionally exporting additional facts) or in other ways without storing it in Netbox.
• For the naming convention of the Device Types in Netbox we came up with two alternatives, and @wiki_willy will follow up with the DCOps team to get a final feedback. The two options are (see image below):
  • Config{LETTER} YYYYMM - {model}
    • This way all the configs will be sorted naturally by type of config (A, B, ...) and version (year month), but will be detached from the original model (R440) that will still be used for hosts that are not part of any standard config.
  • {model} - Config{LETTER} YYYYMM
    • This way all the configs will be close to the original model (R440) and then sorted naturally by type of config (A, B, ...) and version (year month)
  • 
• Keeping the device type under the original manufacturer and original model in the name allows also in the future to have the same config (ConfigA) available from multiple different vendors, while allowing to easily distinguish between them.
• As for the limitation that packing multiple information in the device type name (config, date, model) doesn't allow to free-text filter between them, it was deemed not an issue as this type of search will happen rarely and is still possible from the UI just adding more device types to the filter. If at some point a different need will arise we might create a simple script that using the API returns what's needed.

As for next steps, as soon as we get a final feedback between the two possible naming conventions we can create the device types and start using them.

Thanks Riccardo, that sums the call up well I thinl.

Overall this is something DC-Ops need so I'm happy for them to define it, but I'll share my thinking on what I think the considerations going into that are. I don't think I did a very good job of explaining on the call given my technical issues.

Grouping

The first question is how we group servers into the different categories/configs. Willy's spreadsheet gives a good example of what this might be like. First and foremost the devices are categorized according to a specific build from Dell/price, with the number of CPUs, RAM, DIMM setup, drives etc. defined for each.

With that kind of approach 2 main considerations strike me:

• What are the specific attributes that, together, make a server belong to one Category or the other?
  • In other words what items would have to change to make a build different enough that it gets it's own "Config" letter/category.
• What changes from an existing, "Config A" for example, merit it being defined as a new _version_ of that same config?
  • i.e. What items, if changed, would cause us to move from "Config A 202011" to "Config A 202107"
  • Would we keep the same config and verison number for a few years in a row if we didn't need to change the HW spec for it?
  • If the HW stayed the same but the price changed significantly would that affect anything?

Ranges

If we stick with the hardware-based definitions like on Willy's sheet another option also occurs to me. Which is, given we said we probably don't want to be overly specific, could we instead define specific "ranges" for each of Config/Category. So we have flexibility on one side, but a clear definition of what should be in each? For example we could define specific bands like:

Config A:  1 Core, 16-32GB RAM, <200GB Disk
Config B:  2 Cores, 32-128GB RAM, 200-500GB Disk
COnfig C:  2 Cores, 128GB+ RAM, 500GB+ Disk.

Use-cases for the configs / groups

What exactly are we mapping this out for? Off the top of my head there are some interrelated, but different motivations we might have. Worth thinking through and making sure we know exactly what we need to get out of the exercise. Are they for:

• Bundle/SKU/cost tracking for ordering from Dell/vendor.
• Recording "like for like" hardware in our inventory (that could be swapped for each other?)
• Recording HW against the annual budget? Is that why the FY is important?
• Are all groups unique? i.e. is there any reason we might want to define two sepatate "configs", that actually have the same HW spec?
  • What's the reason for the different configs in that case?
• Defining configs/categories of box we use for a given WMF purpose, i.e. MediaWiki box, DB server etc.
  • With this the versions of a different Config from year to year might no longer be machines of similar power / HW, we're using the groups for something else.

WMF Purpose -> Config Mapping

If we take that the config's are HW specs, and go with an approach where they represent a "class" of hardware (i.e. Config 'A' powerful, high cpu, low storage, Config 'B', high storage, lower CPU etc.), would it make sense to have a separate mapping of the WMF server use-cases to those HW configs? So for instance we could maintain a table of which HW config we currently use to deliver each kind of server:

Anyway just some thoughts I figured I'd share. DC Ops I think need to make the call on how they'd prefer this to be set up, and we can pick it up and work on the Netbox side.

Like we said on the call the definition of each config doesn't have to be any more specific than is useful to us. But we should try to be clear about what we want to get out of it, and what our criteria for the group definitions are. If we try to make it all things to all people we probably won't be able to make it work. We should define what DC-Ops need to get out of it precisely, and make sure we tick those boxes.

I will go for: PowerEdge R440 - Config A 202107

Great, we have a winner. Thanks everyone for the help!

I went ahead and created all the device types based on Willy's spreadsheet, you can see them all here.
They can be used as any other device type in Netbox.

@wiki_willy Is there anything else here to do or we can resolve this task? I'll leave it to you to update the related DCOps documentation/workflow to pick the right device type when adding hosts to Netbox.

Thanks @Volans, I think we're good. If we're all set now, @Papaul, @Jclark-ctr, @Cmjohnson, and @RobH can proceed with using the new naming device type conventions. Thanks, Willy

FYI, Netbox is alerting with:

mismatched device models: PowerEdge R740xd2 - ConfigJ 202107 (netbox) != PowerEdge R740xd2 (puppetdb)

In T284614#7280751, @ayounsi wrote:

FYI, Netbox is alerting with:

mismatched device models: PowerEdge R740xd2 - ConfigJ 202107 (netbox) != PowerEdge R740xd2 (puppetdb)

Thanks, I'll look at it.

Change 714377 had a related patch set uploaded (by Volans; author: Volans):

[operations/software/netbox-extras@master] reports/puppetdb: support WMF standard configs

https://gerrit.wikimedia.org/r/714377

Change 714377 merged by jenkins-bot:

[operations/software/netbox-extras@master] reports/puppetdb: support WMF standard configs

https://gerrit.wikimedia.org/r/714377

In T284614#7280751, @ayounsi wrote:

FYI, Netbox is alerting with:

mismatched device models: PowerEdge R740xd2 - ConfigJ 202107 (netbox) != PowerEdge R740xd2 (puppetdb)

This has been fixed. All the outstanding errors in that report are real mismatch

I think we're close to being able to mark this as resolved.

@wiki_willy Should we have any kind of reports to prevent entry mistakes?
What would be the consequences of such mistakes?

Thanks for checking @ayounsi. Just to confirm, will the previous Netbox alert error that Riccardo had fixed, continue checking for any configuration mismatches?

mismatched device models: PowerEdge R740xd2 - ConfigJ 202107 (netbox) != PowerEdge R740xd2 (puppetdb)

If that still checks for any entry mistakes, I think that should cover things for now.

It checks if the model is the correct one, but doesn't check for the Config version.
So that covers some entry mistakes but not any.

Thanks for confirming @ayounsi. I don't know how much effort it would be to pull the CPU, memory, or hard drive specs on each server and compare it to the config version as an additional check, but I kind of wonder if it's worth the additional time. There would also be a lot of upkeep going forward, as the internal components continue to evolve for each config version every year. Since we would primarily reference the config version when either a) repurposing hosts or b) cannibalizing parts off a decom'd server (which I don't see happening too often), I think a partial check on the model seems good for now. I'm totally open though if folks want to go different direction with this. Thanks!

In T284614#7857195, @ayounsi wrote:

It checks if the model is the correct one, but doesn't check for the Config version.
So that covers some entry mistakes but not any.

Is there anything left on this task?