[zibi-pplx]

Summary

The observability install, which Kind CI's shards run while the Rust producer builds and local bring-ups run from the Tiltfile, now pulls and loads its images in parallel. The metrics and traces releases also install at once.

Why. The install did everything one step at a time:

• six mirror pulls, about 23 s in CI;
• six kind loads onto every node, about 57 s, Prometheus alone 30 s;
• four Helm releases with --wait, about 60 s.

PRs that change Rust now build incrementally from main's state, and the producer often finishes before this install does. That puts the install's 2.5 minutes on a shard's critical path.

What changes in infra/space/kind/scripts/install-observability.sh:

• Pulls. The first mirror pull runs alone, so it is the only one that logs in with GHCR_TOKEN and no two docker logins write the Docker config at once. The rest run in parallel.
• Loads. The kind loads run in parallel.
• Releases. The metrics and traces releases, each its own chart in its own namespace, install at once. The logs and Grafana releases keep their order after them, as test_otel_installs_only_selected_local_receivers requires.
• Output. Each parallel command's output is printed in queue order, and any failure still fails the install.

Value. The install takes about 2.0 minutes instead of 2.5-2.6, about 0.5 minutes off each shard's preparation. The required check gains that whenever the producer finishes before the shard's preparation, which is now the usual case.

Stack

1. #1267: eight shards, balanced across both API surfaces.
2. kind: install the observability profile's images and receivers in parallel #1268 (this PR): install the observability profile's images and receivers in parallel.

Validation

• scripts/tests/test_kind_observability_helpers.py passes (15 tests) in a Linux container, as CI runs it. macOS's bash 3.2 fails two of them on main too, on an unbound empty array in infra/space/kind/lib/release.sh.
• Kind CI: the "Install the observability profile" step's slowest shard took 1.9, 2.1, 1.9, 2.0, 1.9 and 2.1 minutes in the six runs that include this change. The runs without it in the same stack took 2.6 and 2.5 minutes. Every shard passed.

Per-phase timing in one shard, from the step's output:

Phase	Before	With this PR
Mirror pulls	about 23 s	about 7 s for the first pull, which runs alone, then about 21 s for the rest in parallel
Loads	about 57 s	about 40 s
Metrics and traces releases	about 23 s	about 13 s together
Logs and Grafana releases	about 37 s	about 40 s, unchanged in order

The pulls and loads are now bound by bandwidth and disk, not by running one at a time.

Severity and risk

Severity: does not apply; this is a CI speedup.

Risk:

• Parallel kind loads and pulls use more disk and network at once on the shard runner, and in a local bring-up.
• A failed command is now reported after its batch finishes, with its output, instead of as it happens.
• Revert this PR to roll back.

Not covered

• The remaining 2 minutes are mostly loads and the ordered logs and Grafana releases. Baking these images into the Kind node image would remove the loads. No smoke scenario reads Grafana, so CI could skip it.

AI assistance: Claude Code drafted the change and this description.

🤖 Generated with Claude Code

[ac-pplx]

Each Kind CI shard installs the observability backends while the Rust producer builds. That means six mirror pulls, six kind loads onto every node and four Helm releases, run one after another. When the producer reuses main's image or builds incrementally, it finishes first, and the install sits on the shard's critical path. This PR runs the pulls, the loads and the metrics and traces releases in parallel.

"Install the observability profile" step, eight shards each
#1267's head  2.4-2.7 min   mirror pulls one by one, 25-36 s
this head     1.7-1.9 min   first pull alone 4-8 s, then the other five together in 9-13 s

The runs are #1267's and this head's. A failed metrics or traces release still fails the install: run_queued returns 1 as the last command of its || list, so set -e applies.

Verdict: Approved; 1 thread to resolve before merge.

Before merge (inline threads)

1. The README and the commit message overstate what runs in parallel and what fails

Nits

• In CI the first mirror pull runs alone without guarding anything. The install step does not set GHCR_TOKEN (.github/workflows/kind-ci.yml:369-376); the job logs in at its "Log in to GHCR" step. So registry_login returns at once for every pull, and the first pull costs 4-8 s per shard for nothing. Serialise it only when GHCR_TOKEN is set.
• run_queued prints a batch's output only after every command in it exits. A cold local Tilt bring-up therefore shows nothing through the loads and the metrics and traces Helm waits (up to 5 minutes for traces), although the Tiltfile runs the installer to "show progress" (Tiltfile:141). A log line naming the batch when it starts would fix that.
• The body's timings come from an earlier head stacked on #1266, which has since closed. The runs above reproduce them; cite those runs instead.

[ac-pplx]

The README and the commit message overstate what runs in parallel and what fails. infra/space/kind/README.md:799. "The pulls and the loads run in parallel" holds only for the mirror pulls in GitHub CI. Elsewhere the Docker Hub pulls still run one at a time (infra/space/kind/scripts/install-observability.sh:82-86). The commit message says "any failure still fails the install". The squash message is built from commit messages, so main keeps that text. A failed pull or load still only warns, by design (:65-66, :72-73, :107-110).

Suggested README text: "In GitHub CI the mirror pulls after the first run in parallel; elsewhere the images are pulled one at a time. The loads run in parallel, and the local metrics and traces releases install at the same time; the logs and Grafana releases follow them in that order. A failed release fails the install; a failed pull or load only warns, as before." In the commit message: "a failed release still fails the install; a failed pull or load still only warns."