Repository navigation
Workload preset cmdlets are non-functional: every write and every name-scoped read needs context_names=<fleet> #79
Description
Activity
Live-smoked against Fusion Phase 1. Fixed — all five non-functional operations now work, so closing.
Run
Array FB-A (simulator), Purity//FB 4.8.2, REST 2.26, coordinator of fleet cc-test-fleetIdentity directory account (a local account cannot carry a fleet context) Code under test main@ea4d3eaContext Set-PfbContext -Context cc-test-fleet -Kind FleetDate 2026-08-19 Results
Step Call Context Outcome 1 Get-PfbPresetWorkload(unfiltered)none Pass — 1 preset, 208 ms 2 New-PfbPresetWorkload -Name pslivetest-preset-1 -Attributes …fleet Pass, 1351 ms 3 Get-PfbPresetWorkload -Name pslivetest-preset-1fleet Pass — 1 row, 209 ms 4 Get-PfbPresetWorkload -Name pslivetest-preset-1none Fail — deliberate control, 19 ms 5 Set-PfbPresetWorkload -Name pslivetest-preset-1 -Attributes …(PUT)fleet Pass, 288 ms 6 Update-PfbPresetWorkload -Name pslivetest-preset-1 -NewName pslivetest-preset-2(PATCH)fleet Pass — renamed, 325 ms 7 Remove-PfbPresetWorkload -Name pslivetest-preset-2(DELETE)fleet Pass, 413 ms 8 Get-PfbPresetWorkload -Name pslivetest-preset-2fleet Fail — deliberate negative, FlashBlade API error (HTTP 400): Preset does not exist.Against the table in the issue body:
Finding on 2026-08-02 Now Get-PfbPresetWorkloadunfiltered — worksstill works (step 1) Get-PfbPresetWorkload -Name—Preset does not exist.works with a fleet context (step 3) Set-PfbPresetWorkload -Name—Preset does not exist.works (step 5) New-PfbPresetWorkload—Creating a preset in the array context is not supported.works (step 2) Remove-PfbPresetWorkload -Name—Preset does not exist.works (step 7) Update-PfbPresetWorkload— not tested, expected to fail the same wayworks — PATCH rename succeeded (step 6) The control row is the interesting one
Step 4 repeats step 3 with no context and still fails, correctly — but no longer the way this issue recorded. It never reaches the array (19 ms, no HTTP status). The required-context gate refuses it client-side:
GET /presets/workload targets a fleet-scoped resource and requires a fleet context, but none is set. Set one with
Set-PfbContext -Context <fleet> -Kind Fleet, or run this call in one withInvoke-PfbInContext -Context <fleet> -Kind Fleet { ... }. Get the fleet name fromGet-PfbFleet.The old behaviour was the array's own
code 6 "Preset does not exist.", which is what made this family hard to diagnose in the first place: a context problem presenting as a missing object. That substitution is a second improvement beyond the five fixes.Cleanup
No residue. A post-run read of the fleet preset list returns only the standing test fixture; both
pslivetest-presets are gone (the rename means only one object ever existed).One incidental observation, not a defect
The unfiltered no-context read returns the fleet-qualified name
cc-test-fleet:lt-fixture-preset, while the same preset read with a fleet context returns the barelt-fixture-preset. That is the array's own framing of the locally replicated copy versus the fleet-database record, not module behaviour.Closing: live-verified fixed on main@ea4d3ea against FB-A with a fleet context. Evidence in the comment above.
Five of the six workload-preset operations do not work and never have. This is a
record of the finding and its cause, not a request for a separate fix — the fix
is already planned as part of the Fusion context work (#72). Filing it so the
state is written down rather than rediscovered.
What's broken
Every preset write, and every name-scoped preset read, requires
context_names=<fleet>. No cmdlet inPublic/Presets/has ever sent it.Tested against FB-A (Purity//FB 4.8.2, REST 2.26, coordinator of fleet
cc-test-fleet) on 2026-08-02, as a dynamic-authorization-model admin, against apreset that genuinely existed — seeded over raw REST with fleet context, then read
back with every cmdlet in the family:
Get-PfbPresetWorkload(unfiltered)Get-PfbPresetWorkload -NameFlashBlade API error: Preset does not exist.Set-PfbPresetWorkload -NameFlashBlade API error: Preset does not exist.New-PfbPresetWorkloadFlashBlade API error: Creating a preset in the array context is not supported.Remove-PfbPresetWorkload -NameFlashBlade API error: Preset does not exist.Update-PfbPresetWorkloadOnly the unfiltered
Getworks.Why
/presets/workloadis a fleet-scoped endpoint — a preset lives in the fleetdatabase, not on any one array. Measured behavior on that endpoint:
code 13/code 6. The local-context short-circuitthat makes a plain
GETsucceed does not apply to writes.code 13 "Invalid context."Only the barefleet name is ever accepted, on every verb.
GET ?names=→code 6, even though the unfilteredGETreturnsthat same preset. The local view is list-only: enough to enumerate, not enough to
resolve a name against.
So this is one cause with five symptoms, not five bugs.
What fixes it
The Fusion context work in #72 — a
-Contextparameter,Set-PfbContext, andcentral injection of
context_namesinInvoke-PfbApiRequest. Once a fleet contextcan be set and injected, all six operations start working together; nothing in
Public/Presets/needs individual repair.Two dependencies worth naming:
Set-PfbPresetWorkloadontoInvoke-PfbApiRequest.It was the last preset cmdlet hand-rolling its own
Invoke-RestMethod, so it wouldhave been skipped by central injection entirely. That PR does not make the cmdlet
work — it makes it reachable by the thing that will.
a fleet-scoped endpoint should do when no context is set. Array-scoped endpoints
default sensibly to the local array; fleet-scoped ones have no such default, so the
options are send-and-fail, throw client-side, or default to the fleet. Whichever is
chosen decides what these cmdlets do out of the box.
A note on testing this
As a static-authorization-model admin (
pureuser, any local user, any serviceaccount) every call to this endpoint returns
code 20 "Operation not permitted."—read and write alike, whatever the context. That is indistinguishable from the
endpoint being unsupported on the platform, and it did produce exactly that wrong
conclusion during #76 testing. Re-running as an LDAP/SAML admin
(
authorization_model: dynamic) turns the same calls into real semantic errors.Anyone reproducing the table above needs a dynamic-model admin.
Scope
Presets are the family that was measured. The same failure mode applies to any
cmdlet calling a fleet-scoped endpoint without context, and the capability map
records which endpoints declare
context_names, so the affected set is measurablerather than speculative. That sweep has not been run.
Evidence and design consequences are recorded in
docs/design/fusion-context-injection.mdon #72 — see "Fleet-scoped mutations haveno usable default", section 11, and Appendix A.