Skip to content

Harden CI deploy timeouts for heavier post-upgrade images - #38

Closed
klagrida wants to merge 2 commits into
mainfrom
fix/jupyter-rollout-timeout
Closed

Harden CI deploy timeouts for heavier post-upgrade images#38
klagrida wants to merge 2 commits into
mainfrom
fix/jupyter-rollout-timeout

Conversation

@klagrida

@klagrida klagrida commented Jun 6, 2026

Copy link
Copy Markdown
Contributor

Summary

After #34 (Spark 3.5→4.0.1, Airflow 3.0.2→3.1.7), E2E Tests (Linux) and the Cluster Integration Test started failing on main. Root cause is image-pull saturation, not a broken component: the upgrade increased the total image bytes pulled onto the single minikube CI node, so whichever deployment loses the pull lottery exceeds its timeout. The failure moved between runs:

  • platform-tests run: Jupyter came up fine (1m6s), but Airflow was still pulling when the 15-min step timeout killed the step.
  • ci run: Airflow deployed fine (6m17s ✅), but Prometheus + Grafana hit Terraform's default 10-min rollout wait and failed.

E2E was green on every commit before #34 and fails reproducibly after, so this is a real (timing-dependent) regression introduced by the heavier images.

Change — give the heavy deploys consistent headroom

Where Before After
kubernetes_deployment_v1.jupyter default 10m wait timeouts.create/update=20m, progress_deadline_seconds=1200
kubernetes_deployment_v1.prometheus default 10m wait same 20m / 1200
kubernetes_deployment_v1.grafana default 10m wait same 20m / 1200
helm_release.airflow timeout 900s (15m) 1500s (25m)
Deploy step timeout-minutes (platform-tests) 15 30
Deploy step timeout-minutes (ci) 20 30

Also adds .claude/ to .gitignore (harness state).

Durable fix

These timeouts are a band-aid for slow image pulls. The real fix — pinning smaller/maintained images (esp. the ~4 GB jupyter/pyspark-notebook:latest) and/or pre-pulling — is tracked in #36.

Verification

  • terraform fmt / terraform validate
  • ⏳ Relying on this PR's E2E + Cluster Integration runs to confirm green end-to-end.

🤖 Generated with Claude Code

E2E Tests (Linux) started failing on main after #34 bumped the Spark
images (3.5.0 -> 4.0.1). The larger images increase pull contention on
the constrained minikube CI node, pushing the (unpinned, ~4GB)
jupyter/pyspark-notebook:latest image past Terraform's default 10m
rollout wait:

  Error: Waiting for rollout to finish: 1 replicas wanted; 0 replicas Ready
    with kubernetes_deployment_v1.jupyter

The image was at 9m40s and still pulling when the wait expired, while
Prometheus/Grafana each took ~5.5m on the same node, confirming it's
slow image-pull, not a real deploy error.

Add a 20m create/update timeout and bump progress_deadline_seconds to
1200 on the Jupyter deployment. Durable fix (pinning a smaller image)
tracked in #36.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The #34 version bumps (Spark 3.5->4.0.1, Airflow 3.0.2->3.1.7) increased
total image bytes pulled onto the single minikube CI node. With more
pull contention, whichever deployment loses the image-pull lottery
exceeds its timeout - the failure moved between runs (jupyter, airflow,
prometheus, grafana) rather than being one broken component:

- platform-tests run: airflow still pulling when the 15m step timeout hit
- ci run: airflow deployed fine (6m17s) but prometheus/grafana hit the
  provider's default 10m rollout wait

Give the heavier deploys consistent headroom:
- prometheus + grafana: timeouts.create/update=20m, progress_deadline=1200
  (matching the jupyter fix in the previous commit)
- airflow helm_release: timeout 900 -> 1500 (25m)
- Deploy step timeout-minutes: platform-tests 15 -> 30, ci 20 -> 30

Durable fix (smaller/pinned images, pre-pull) tracked in #36.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@klagrida
klagrida force-pushed the fix/jupyter-rollout-timeout branch from 010187e to 09ed132 Compare June 6, 2026 01:13
@klagrida klagrida changed the title Fix: give Jupyter deployment more rollout headroom in CI Harden CI deploy timeouts for heavier post-upgrade images Jun 6, 2026
@klagrida

klagrida commented Jun 6, 2026

Copy link
Copy Markdown
Contributor Author

Obsolete after #39 reverted the version-drift change. With the lighter baseline images restored, CI deploys complete in ~11–13min and no longer need the extended timeouts this PR added.

@klagrida klagrida closed this Jun 6, 2026
@klagrida
klagrida deleted the fix/jupyter-rollout-timeout branch June 6, 2026 09:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant