Run cff9b348-bfc3-4ac1-ab51-a94892b8e3a0 of loosely_coupled_k8s_job reached RUN_SUCCESS in dataprovider01 on sandbox-cat-dat: four payload Jobs, four distinct payload pod hostnames in contributing_hosts, and the payload log lines in the run log. Checks L4-L10 are now observed rather than derived. Torn down afterwards; the namespace was left as it was found.
Corrects two claims that were wrong. The registry does NOT require a pull secret - a bare GET returns 401, but that is the opening move of the Docker token handshake, and completing it anonymously returns the manifest for both images. And PIPES_PAYLOAD_NAMESPACE was set to a namespace named dagster, which does not exist on that cluster; the release is called dagster but runs in dataprovider01.
Adds the sandbox probe variant. The generic probe cannot run there: sandbox access is Rancher project-scoped, so a new namespace grants its creator nothing and Role creation is denied everywhere. It is not needed either, since dagster-role already carries the exact pipes permissions.
Changelog: added
dagster 1.12.8 has no per-deployment imagePullSecrets field: deployment-user.yaml reads the dagster-user-deployments subchart value and the run launcher helper reads the parent chart value. The pull secret nested under the deployments[] entry was silently discarded, which would have produced ImagePullBackOff against a values file that reads as correct.
Also records the unresolved 1.13.19 vs 1.12.8 skew between these images and the sandbox control plane.
Changelog: fixed
This repository is built by the shared ds.gitlab-ci.yml template; carrying a second CI system alongside it invited the reader to wonder which one is authoritative. The Gitea Actions workflow that builds both images stays in the sandbox Gitea mirror, which is where the sandbox images are produced.
The README, the pipes payload values and the sandbox values no longer point at a file this repository does not contain.
Changelog: removed
yaml/sandbox/values-sandbox-gitea.yaml carries the registry coordinates, the pull secret both namespaces need, and the commit SHA the two images share. The sandbox registry rejects anonymous pulls, so a payload namespace without its own pull secret leaves the dispatching op waiting on a pod that never starts - readiness check L4 now says so.
Changelog: added
