[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. In GitHub CI the mirror pulls run in parallel. With GHCR_TOKEN set, the first pull logs in alone before the rest, so no two docker logins write the Docker config at once; CI logs in at its own step and does not set it. Elsewhere the images are still pulled one at a time.
• 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 batch is logged as it starts, and its commands' output is printed in queue order once it ends. A failed release still fails the install; a failed pull or load still only warns, as before.

Value. The install takes 1.7-1.9 minutes instead of 2.4-2.7, about 0.7 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 across eight shards:

Run	Install step	Mirror pulls
#1267's previous head (run)	2.4-2.7 min	one by one, 25-36 s
this PR's previous head (run)	1.7-1.9 min	the first alone in 4-8 s, then the other five together in 9-13 s

At this head CI no longer runs the first pull alone, which should save those 4-8 s. Its CI is running. Every shard passed.

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.

[zibi-pplx]

Thanks for the review. The inline thread is fixed in 789a35c. On the nits:

• First pull: agreed, it ran alone for nothing in CI. It now runs alone only when GHCR_TOKEN is set; otherwise all mirror pulls start together.
• Progress during a batch: run_queued now logs <batch>: N at once when a batch starts, so a cold Tilt bring-up shows what it is waiting on. An empty load batch is skipped instead of logged.
• Timings: the body now cites the runs you linked: install 2.4-2.7 → 1.7-1.9 min.