Files
distributed-execution/yaml/sandbox/values-sandbox-gitea.yaml
ILay 96caa3f81b [SIMPL-30451] Verify the Kubernetes pipes transport on the sandbox
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
2026-08-31 19:41:26 +02:00

61 lines
2.9 KiB
YAML

# Sandbox deployment values - Gitea registry.
#
# NOT CLUSTER-VERIFIED. The images and the registry behaviour here are confirmed
# - a probe pod ran from them on the sandbox on 2026-08-31 - but these values
# have never been applied as a code location. Registering this service against
# the sandbox Dagster is still blocked on the version skew below.
#
# VERSION SKEW, unresolved. These images carry dagster 1.13.19 (requirements.txt
# pins no upper bound, so the build took whatever was current). The sandbox
# control plane is 1.12.8. A code server is a gRPC server the webserver and
# daemon call into, so the two versions have to be compatible; a minor-version
# gap is not a supported configuration. Pin dagster to the control plane version
# and rebuild before reading a failure here as a bug in this service.
#
# Use these instead of the code.europa.eu references in
# yaml/values-dagster-distributed-execution.yaml and
# yaml/loosely-coupled/values-pipes-payload.yaml when deploying to the
# dataprovider01 sandbox. Both images were built and published by a Gitea Actions
# workflow held in the sandbox Gitea mirror of this repository, not here.
#
# The tag below is a short commit SHA and is the same for both images. That is
# the version lock: the code location and the payload it dispatches must come
# from one commit. Bump both together or not at all.
#
# The Gitea images are anonymously pullable, so NO pull secret is needed. A bare
# GET to the registry returns 401, which reads as a refusal but is only the start
# of the Docker token handshake; completing it anonymously and re-requesting the
# manifest returns 200 for both images. This was confirmed on 2026-08-31, and a
# probe pod carrying no credentials pulled and ran on the sandbox.
#
# An earlier revision of this file required a pull secret on both the deployment
# and the run launcher. That was wrong, and wrong in an expensive direction: it
# sent the reader looking for credentials that do not exist.
dagster:
dagster-user-deployments:
deployments:
- name: distributed-execution
image:
repository: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution
tag: 5122da4691f9
pullPolicy: IfNotPresent
env:
- name: PIPES_PAYLOAD_IMAGE
value: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution-payload:5122da4691f9
# The sandbox release is named `dagster` but lives in dataprovider01;
# there is no namespace called `dagster` on that cluster.
- name: PIPES_PAYLOAD_NAMESPACE
value: dataprovider01
runLauncher:
config:
k8sRunLauncher:
runK8sConfig:
containerConfig:
env:
- name: PIPES_PAYLOAD_IMAGE
value: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution-payload:5122da4691f9
- name: PIPES_PAYLOAD_NAMESPACE
value: dataprovider01