Server SKUs¶
A server SKU is one of your standard builds, saved against your own
reference — OS-32C-BASE-R7715, GPU-8xH100, whatever you already call it
internally. Save it once, and anyone in your organisation adds it as a
simulation target by picking it from a list instead of retyping the
specification.
Your reference then travels with the work: it appears on the target, in the run results, and in the PDF report.
Administrators define them, everybody uses them
The SKU list is the vocabulary your organisation's simulations are described in, so defining and editing it is an administrator's job. Every member can pick from the list.
The SKU list¶
Organisation Admin → Server SKUs lists every build you have defined, with its status. We match each SKU against the hardware catalogue when you save it, so the list tells you straight away whether a build is ready to use.
The statuses are the same as on a simulation's server list:
| Status | What it means | What to do |
|---|---|---|
| Graded | In the catalogue, and graded | Nothing |
| Grading… | In the catalogue; the grade is on its way. The page updates itself, usually within a minute | Nothing |
| Not graded | In the catalogue, but our supplier has no grade for it | Change the server or CPU to one that is graded |
| Not in catalogue | The build did not match, or part of it is not in the catalogue. That part is shown in red | Edit the SKU and pick a catalogue entry |
| To check | We matched the build, but only as a best guess | Edit the SKU, check the match, then Confirm match or change it |
The grade itself appears in your simulation results, not here.
The model and CPU columns show the catalogue's names for what the SKU matched. Show your definition switches them to what you typed. The line above the list counts each status, and the buttons under it show one status at a time.
The Cores column comes from the configuration we matched, not from what was
typed — so it is also a check on the match. A build called OS-32C whose cores
read 16 has matched the wrong CPU.
Defining one¶
New SKU asks for:
| Field | Notes |
|---|---|
| Reference / SKU | Your own code. Must be unique within your organisation |
| Vendor, Model, CPU | What the build is, as the catalogue would name it |
| CPUs, Memory (GB) | The configuration |
| GPU, GPU count | Optional. Leave blank for a CPU-only server. Only shown if GPU support is enabled for your organisation |
Vendor, model, CPU and GPU suggest as you type, from the same catalogue the Add Target form uses, and a build we cannot place exactly shows a "did you mean" panel underneath with the closest matches. Taking the suggestion is worth it: a SKU is typed once and used for years, so an unrecognised spelling here costs a grade on every simulation that picks it.
There is no quantity. A SKU says what a server is, never how many you own — how many you would buy is asked when the SKU is used, because that is a question for one simulation rather than for the definition.
Importing a spreadsheet¶
Most organisations already keep their standard builds in a spreadsheet. The dropdown beside New SKU has Import from CSV, which takes it as it is.
- Upload your file. Nothing is imported yet.
- Map your columns. Every row is a field we understand, and the dropdown
beside it is the column from your file we think matches. We recognise the
usual spellings —
Make,Sockets,RAM (GB),SKU Reference— so the screen usually comes up answered. Change anything that looks wrong. Reference, vendor and model must be mapped. - Import. The SKUs are created and matched against the catalogue, and the list shows each one's status. Filter to Not in catalogue or To check to see the ones that need attention.
Any other columns are ignored, including a quantity column — see above.
Download Template in the same dropdown gives you a CSV in the shape we expect, if you would rather start from scratch.
Rows that are refused¶
A reference must be unique within your organisation, so a row is refused if its reference is already in use — by an existing SKU, or by an earlier row in the same file — or if it has no reference, vendor or model at all.
Refused rows are named individually, with the row number and the reason, above the list. Everything else in the file is imported: one bad row does not cost you the upload.
Using a SKU¶
On any simulation, Add Target has a From SKU option. It lists your organisation's SKUs with their status. Tick as many as you want, then Add selected adds a target for each.
On a host-to-host simulation, each SKU also has a quantity: how many of that build you would deploy. Typing a quantity ticks the SKU for you, and a ticked SKU with no quantity counts as one. An estate refresh works out the number of servers itself, so it does not ask.
A SKU that is already a target on this simulation is not added twice. If you give it a quantity, that target's quantity is changed to it; otherwise it is left as it is. The message says which.
Two things happen that are worth knowing about.
The specification is copied. The target takes the SKU's vendor, model, CPU, memory and GPU as its own, along with the SKU reference. It does not point back at the SKU. For a matched SKU, the vendor, model and CPU are the catalogue entries it is matched to — what the SKU table and the picker show — not what you typed. So a SKU whose server you have changed adds a target that is the new server.
The catalogue match is copied too, which is why adding a target this way is immediate: the matching was done when the SKU was saved.
Editing, retiring and deleting¶
Editing a matched SKU shows its server, CPU and (if it has one) GPU separately. For each you see what you typed (In your definition), what it is matched to, and how that was decided. Saving without changing them keeps the match, so correcting the memory or CPU count never undoes it. Change server, Change CPU or Change GPU opens that part only, as a box that lists what the matcher considered and searches the catalogue as you type. Your definition is kept whatever you change. A SKU marked To check also has Confirm match, which accepts the match as it stands.
Editing a SKU that did not match shows its definition to correct. It is matched again when you save.
Editing does not change any target already built from a SKU. Those carry their own copy, so no finished simulation or report can be rewritten by a later edit. To bring an existing target in line with a corrected SKU, either edit the target and Change server, or remove it and add the SKU again. Rerun the simulation for the change to reach its results.
Retire takes a build out of circulation. It disappears from the picker, stays in the admin list marked Retired, and the targets and reports that already used it are untouched. Retiring can be undone.
Delete removes it altogether. Nothing downstream breaks: every target built from a SKU carries its own copy of the specification and the reference it ran with, so the simulations and reports you have already produced stay exactly as they are, still printing that reference.
Which to use:
| Delete | A mistake, a test entry, a junk row from an import — anything nobody has used |
| Retire | A build you have moved on from but have run simulations against. It leaves the picker, and you keep the record of what you standardised on and what those simulations were comparing |
The confirmation tells you how many targets were built from a SKU before you delete it, and suggests retiring instead when there are any.
Where your reference appears¶
- The target row on the simulation page.
- The target headings in run results.
- The target comparison table in the PDF report, where the column appears only if at least one target in the run came from a SKU.
Because the reference is recorded with the run, an old report keeps printing the reference it was run with, whatever has happened to the SKU since.