[SIMPL-30451] Correct stale references in the guide and verify both images build
The rename of process_work_units and _results_from_pipes during the fan-out refactor left three references behind, in the guide, the checklist and the loosely coupled module docstring. The guide also showed loosely_coupled_k8s_job without its executor_def and claimed the pipes client replaced the executor, which stopped being true once the graph fanned out. Both images were built and smoke tested: the code location image loads its definitions, and the payload image ships dagster_pipes without dagster. That check is now recorded as L11 in the readiness checklist, so the isolation argument is verified at image level and not only in the source. Changelog: fixed
This commit is contained in:
@@ -9,8 +9,9 @@ location image.
|
||||
|
||||
> **NOT CLUSTER-VERIFIED.** Checks L4–L9 and the Kubernetes rows of section 4.3
|
||||
> are derived from the implemented reference but have not yet been run against a
|
||||
> Simpl cluster. Checks L1–L3 and L10, which exercise the payload contract, the
|
||||
> message-parsing path and per-unit dispatch, are covered by the test suite.
|
||||
> Simpl cluster. Checks L1–L3, L10 and L11, which exercise the payload contract,
|
||||
> the message-parsing path, per-unit dispatch and image-level isolation, are
|
||||
> verified locally.
|
||||
|
||||
---
|
||||
|
||||
@@ -52,9 +53,10 @@ location image.
|
||||
| L8 | Payload has **no** orchestration connectivity | Same run; inspect run logs | No `Payload could see orchestration runtime credentials` warning. This is a positive check — absence of errors is not sufficient |
|
||||
| L9 | Work ran off-platform | Same run | `summarise_results` metadata shows `contributing_hosts` containing the payload pod names, not the run worker's hostname |
|
||||
| L10 | One workload dispatched per unit | Same run, or `uv run pytest -k dispatched_to_its_own` locally | `contributing_workers` has one entry per unit; the local test asserts four distinct external workers |
|
||||
| L11 | Payload **image** carries no orchestration dependency | `docker run --rm <payload-image> python -c "import importlib.util; print(importlib.util.find_spec('dagster') is not None)"` | Prints `False`. L1 proves the *source* does not import `dagster`; this proves the shipped image does not contain it either |
|
||||
|
||||
Checks L4–L9 require a cluster. L1–L3 and L10 run on a laptop and should gate
|
||||
every change to the payload or the dispatching op.
|
||||
Checks L4–L9 require a cluster. L1–L3, L10 and L11 run on a laptop and should
|
||||
gate every change to the payload or the dispatching op.
|
||||
|
||||
---
|
||||
|
||||
@@ -90,7 +92,7 @@ every change to the payload or the dispatching op.
|
||||
| Op hangs until `pod_wait_timeout` (default 24 h) | Payload Job never scheduled — quota, node selector or image pull | Check `kubectl -n <payload-ns> describe job <name>`; lower `pod_wait_timeout` so the failure surfaces quickly |
|
||||
| `403 Forbidden` creating the Job | Dispatcher service account lacks Job create permission | Apply `yaml/loosely-coupled/rbac-pipes-dispatch.yaml` in the **payload** namespace |
|
||||
| Warning: `Payload could see orchestration runtime credentials` | Payload pod inherited run-pod env or a Vault annotation | Remove the inherited env; the payload should receive only what `extras` and explicit `env` pass it |
|
||||
| Payload exits non-zero but the run reports success | Exit status not being checked, or messages read before failure | Confirm the dispatching op returns through `_results_from_pipes`; do not swallow `PipesClientCompletedInvocation` errors |
|
||||
| Payload exits non-zero but the run reports success | Exit status not being checked, or messages read before failure | Confirm the dispatching op returns through `_result_from_pipes`; do not swallow `PipesClientCompletedInvocation` errors |
|
||||
| Payload receives no `units` | `extras` key mismatch between dispatcher and `pipes.get_extra()` | Both sides must use the same key; a typo yields a `KeyError` inside the payload |
|
||||
| Run cancelled in the UI, payload pod keeps running | Cancellation is not propagated to dispatched workloads automatically | `delete_pod_on_completion` handles the normal path; for cancellation, verify orphaned Jobs and add a cleanup sensor |
|
||||
|
||||
@@ -108,8 +110,9 @@ change record:
|
||||
1. The run ID and its final status.
|
||||
2. The `report_execution_target` output metadata block (pod identity, namespace,
|
||||
env var presence).
|
||||
3. The `summarise_results` metadata block (`contributing_hosts`), which proves
|
||||
which execution target was actually used.
|
||||
3. The `summarise_results` metadata block (`contributing_hosts` and
|
||||
`contributing_workers`), which proves which execution target was actually
|
||||
used and that the fan-out reached it.
|
||||
4. For `k8s_job_executor`, the output of `kubectl get jobs -l dagster/run-id=<run-id>`.
|
||||
5. For the loosely coupled target, the payload image digest and the run log line
|
||||
emitted by `pipes.log` — together they prove which payload version ran and
|
||||
|
||||
Reference in New Issue
Block a user