Repository navigation
Define how to recover an interrupted Longhorn benchmark #5665
Description
🤖 Generated by the Agentic Engineer
Problem
A storage benchmark that stops early keeps its journal and scratch resources for recovery, but no recovery procedure exists. A later run refuses to start while the journal exists. Scratch storage left behind by a V1 run also makes the V2 comparison hold. Today the only way out is working by hand on the cluster.
Acceptance criteria
- An interrupted run can be recovered by a reviewed, confirmed operation that removes only what that run created.
- The operation proves the earlier run has finished before acting.
- The documentation describes it, and a baseline can be measured again afterwards.
Part of #5582
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
Priority
None yet
Start date
None yet
Target date
None yet
Effort
None yet
Projects
- Status
Activity
chore: agent-claim #5665 nonce=f639d50bc03b2691b167d1006cae64a2
fix(storage): register benchmark deletion authorization surface
test(longhorn): register and patch the native admission fixture
chore: agent-claim #5665 nonce=04d850b728dface826e268593e96085e
chore: agent-claim #5665 nonce=2687cdb4a80e9c68537344b2615cde74
devantler commentedon Nov 2, 2026
Recovery remains held. Public Longhorn source tracing found that an instance-create request can remain in flight after its caller times out, stay absent from the native runtime registry, and subsequently start after a delete reported not found. A stopped custom resource and a list observation therefore do not establish a retirement barrier.
The admission safeguards can stop new requests and invalidate older Kubernetes status updates, but cannot cancel a create RPC the instance manager already accepted. An upstream native cancellation or per-instance retirement acknowledgement is needed; terminating the shared storage-manager processes is not a sufficient non-disruptive portfolio alternative for this migration. I am preparing a deterministic regression against the public component before proposing a minimal upstream fix. No cleanup or benchmark acceptance is claimed.
chore: agent-claim #5665 nonce=373dba9e06cb47530114e4a8053182d4
test(storage): exercise actual instance finalizer removal
devantler commentedon Nov 2, 2026
The V1 cancellation fix is locally validated in longhorn/longhorn-instance-manager#1838, but an inherited upstream backport workflow fails validation before any job starts. The failure is present at the upstream base and unaffected by this contribution. No change inside this portfolio can repair that third-party reusable-workflow contract; a minimal public upstream report is necessary to unblock the contribution. Authentication wiring belongs to its maintainers and remains unresolved, so the contribution stays draft rather than claiming CI readiness.
devantler commentedon Nov 2, 2026
A separate native Linux regression at the public instance-manager base
362c0ed7bfe077ab07daa79130c5b827c5f5eeb5reproduced a delayed-start failure: Stop, StopWithSignal and Kill before Run each still allowed a harmless test subprocess to launch. Holding the native command immediately before Run also allowed Process.Stop to finish its not-running branch before the subprocess launched. The active control launched normally; an already-stopped Process also accepted Start.This is outside the pre-registration cancellation patch. A Platform-only state or registry check cannot prevent a delayed native launch, so no in-portfolio alternative supplies that missing guarantee. I am preparing a narrowly scoped public-source V1 start/stop fix and synthetic regression for the owning upstream, without production identities, data or internal review receipts. Hidden replacements and V2 retirement remain separate unresolved gates.
devantler commentedon Nov 2, 2026
The native reusable-workflow validator reproduced the CI blocker in longhorn/longhorn#14454. I prepared the owning central workflow's entrypoint and explicit optional credential contract, preserving its original pull-request event/branch limits and constraining issue linking to the existing destination. Native caller validation, the undeclared-secret negative control, full workflow lint and offline security validation pass.
A portfolio change cannot make that external workflow callable or replace its reviewed caller pin. I am validating the public-source contract in the existing public contributor fork with a credential-free caller before offering the central fix upstream. This changes no platform runtime, forwards no private data or credentials, and does not establish benchmark recovery or V2 readiness.