Skip to content

feat(signal): run one production 15-check certification workflow - #963

Open
Kevin Cho (chokevin) wants to merge 56 commits into
Azure:mainfrom
chokevin:chokevin-upstream-mpijob-adapter
Open

Kevin Cho (chokevin) wants to merge 56 commits into
Azure:mainfrom
chokevin:chokevin-upstream-mpijob-adapter

Conversation

@chokevin

@chokevin Kevin Cho (chokevin) commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Dependency: This PR is blocked on #1001, which publishes the baseline project-signal-runner image. The runner implementation is intentionally not duplicated here. Both PRs use fork branches, so GitHub cannot represent them as a native stack; #963 remains targeted at main and must be rebased onto updated main after #1001 merges.

One immutable CertificationRun reserves one complete participant group and executes exactly 15 ordered checks through one serial Argo Workflow. Argo completion is not certification success: aggregation requires identity-bound task outputs and durable typed backend evidence.

  • Exactly two Signal CRDs: cluster-scoped operator-authored CertificationProfile and namespaced controller-generated immutable CertificationRun.
  • Standalone execution through one fixed adapter WorkflowTemplate. Pod creates one participant-pinned Pod per Node; MPIJob creates one coordinated job with one launcher and one worker per immutable participant. Queue integration is intentionally deferred.
  • One explicit participant policy selects the complete immutable Node group. Empty all-Node selectors, roles, topology assignment, subgroups, and per-check participant filtering are intentionally absent.
  • Participant eligibility is derived from the largest effective per-Node resource request across the 15 checks, including canonical GPU counts. Profiles no longer duplicate that derived resource floor.
  • The Profile pins one operator/GitOps-owned immutable source ConfigMap by name and aggregate SHA-256 digest. The ordered Profile checks define the DAG; the ConfigMap only supplies the selected script bytes. Admission reads the source through the authoritative API reader, rejects binaryData, verifies the aggregate digest before participant selection or Node mutation, copies the exact verified bytes into one Run-owned immutable ConfigMap, and records the aggregate and per-script digests. Scripts remain outside the reusable runner image.
  • Each minimal Profile check specifies only scriptKey, backend, gpuCount, backendActiveDeadline, and a constrained workload policy. The whole-suite Workflow deadline is derived from the 15 immutable backend deadlines plus a fixed evidence reserve; it is not duplicated in Profile or Run spec.
  • Deployment-owned digest-pinned control and runner images are snapshotted or rendered immutably.
  • Signal-owned Node reservation and cordon. Success releases automatically; Failed, Inconclusive, and Canceled Runs remain cordoned until monotonic spec.release: true.
  • Controller and adapter use separate least-privilege identities. CertificationRun mutation is namespace-scoped, adapter Node access is read-only, and API tokens are denied by ServiceAccount default and enabled only on the intended controller or Workflow Pod.
  • Controller and adapter control Pods use restricted security contexts, RuntimeDefault seccomp, bounded resources, and only the Signal-owned cordon toleration needed for recovery.
  • Profile and Run CRDs reject malformed state at API admission, including implicit participant scope, unsafe or duplicate host mounts, invalid MPI GPU counts, mutable runner images, missing identities, duplicate participant names, and malformed script-bundle digests.
  • Run status is intentionally compact: phase/reason, Workflow identity/state, evidence identity, positional check phase/reason, and lifecycle conditions. Measurements, backend identities, backend evidence, and execution timestamps exist only in the digest-bound durable evidence document.
  • Detailed immutable evidence is persisted before controller teardown. Uncertain timed-out or partially created backends are captured and quiesced before later checks can start. Terminal projection and retry cleanup recover completion time from identity- and digest-verified evidence.
  • The public contract excludes generic Workflow wiring, retry/TTL knobs, arbitrary Kubernetes pass-through, arbitrary environment/capability/working-directory configuration, explicit resource-floor duplication, suite-deadline duplication, and queue integration.
  • Production-only controller surface: no tracked Signal test files were added.

Evidence

Architecture overview: narrated 20-second fframes animation covering deployment prerequisites, the operator-owned Profile/scripts, Node request label, immutable admission, serial Argo tasks, and Pod/MPIJob execution.

signal-deployment-trigger-20s.mp4

This is a code-backed architecture animation, not a live execution recording. It correctly shows scripts as operator-owned external inputs rather than runner-image contents, but it predates the final Profile aggregate-digest field and does not visualize that field. Deployment commands contain placeholders and were not executed. Signal does not install Argo, MPI Operator, operator scripts, runner images, or Profiles. The baseline runner image is reviewed and published separately by #1001. The current R01-R15 scripts still do not establish an approved bundled CUDA/NCCL toolchain.

The earlier archival integration explainer showed 15 task nodes, 10 Pass and 5 Inconclusive, before the production-only reduction and lifecycle hardening. Neither video establishes successful certification of the current head. No new live Argo/MPI/GPU run or soak was performed.

Verification

Current head 18b6d171928958ff12dc7837b896eb8bba892153:

  • Rebased onto current main at f91b19dc5fb1777b545a49c115197fe887fe353e; the branch is no longer behind the strict required-check base.
  • Complete PR diff: 32 files, 10,067 insertions and 6 deletions against main.
  • 174 focused offline behavioral assertions pass under the race detector using the ignored standalone harness with fake Kubernetes clients and a local log HTTP server. Coverage includes creation-intent fencing, crash recovery, cancellation/deletion evidence, positional identity hydration, derived suite deadlines, derived participant resource eligibility, exact Node UID ownership, replacement-safe release, orphan reservation recovery, retained cordon repair, complete-group selection, compact non-churning Run status, Pod scheduling on exact participant identities, one coordinated MPIJob with one worker per participant, complete launcher/worker Node-UID evidence, evidence-before-MPI cleanup, immutable source-script enforcement, source binaryData rejection, aggregate and per-script digest verification, recovery-time bundle verification, mounted-script digest verification, long-name MPI uniqueness, per-check wall-clock timeout and quiescence, evidence-gated cleanup, interrupted chunk-generation recovery, least-privilege RBAC, token opt-in, image immutability, Pod hardening, and generated CRD guards.
  • Signal API, controller, adapter, workload, and command packages compile; they intentionally report [no test files].
  • Focused race-enabled package checks, go vet, make signal-manifests, Kubernetes apiextensions static CRD/CEL validation, the 174-assertion offline harness, and git diff --check pass locally.
  • Exact-head CI is green for 18b6d171928958ff12dc7837b896eb8bba892153: 33 checks passed and one non-applicable update job skipped. The sole initial failure was an unrelated external TLS timeout in Racer e2e; its unchanged rerun passed.

Remaining limits and review guide

No committed Signal regression suite and no new real-cluster verification. Foreground garbage collection/RBAC, Argo output persistence, MPI Operator cleanup ordering, GPU runtime injection, and the final approved R01-R15 tool requirements still need deployment-level validation.

Review api/signal/v1alpha1/ for the two CR contracts and canonical bundle digest; internal/signal/controller.go, evidence.go, and projection.go for admission, recovery, audit, cleanup, and release; internal/signaladapter/ for backend execution and evidence capture; and deploy/signal/ for least-privilege RBAC, templates, image contracts, and operator documentation. Review the baseline execution image separately in #1001.

AI assistance: GitHub Copilot assisted with implementation, investigation, validation, video preparation, and PR drafting. Independent review used Claude Opus 5.5 and GPT-6 Astra. The architecture video's narration was synthesized locally. No human verification or approval is implied.

@chokevin Kevin Cho (chokevin) changed the title feat(signal): add participant backend adapter feat(signal): add grouped certification and backend execution Oct 20, 2026
@chokevin
Kevin Cho (chokevin) marked this pull request as ready for review October 21, 2026 01:33
@chokevin
Kevin Cho (chokevin) requested a review from a team October 21, 2026 01:33
@chokevin

Copy link
Copy Markdown
Contributor Author

Typed workload policy, Pod queue labeling, MPI worker isolation, and focused contract tests (15 seconds):

signal-workload-policy-evidence.mp4

@chokevin Kevin Cho (chokevin) changed the title feat(signal): add grouped certification and backend execution feat(signal): run grouped certification suites Oct 22, 2026
@chokevin Kevin Cho (chokevin) changed the title feat(signal): run grouped certification suites feat(signal): run one production 15-check certification workflow Oct 23, 2026
@chokevin

Copy link
Copy Markdown
Contributor Author

Copilot-generated 20-second fframes explainer. The source excerpts remain present in the production cleanup fixes. The recorded integration is explicitly archival, before the final production-only trim: 15 task nodes, 10 Pass and 5 Inconclusive. This is not a new live run or evidence that the updated head passed certification. The updated implementation is being validated separately; the live cluster and soak were not modified.

signal-pr963-20s.mp4

@chokevin

Copy link
Copy Markdown
Contributor Author

Updated 20-second fframes architecture explainer with local narration: why Signal is needed, how the controller/CRDs/RBAC/adapter template are deployed alongside Argo, operator-owned scripts and Profile, the exact Node request label, immutable admission, serial tasks, and script execution in Pods/MPIJobs. This is an architecture animation, not a live execution recording. Placeholder deployment commands were not executed. It supersedes the archival clip as the architecture overview, not as runtime validation.

signal-deployment-trigger-20s.mp4

@chokevin
Kevin Cho (chokevin) force-pushed the chokevin-upstream-mpijob-adapter branch from 6b2bb2c to feee8be Compare October 26, 2026 20:34

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant