You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test(e2e): drop in-container kubeadm upgrade scenario; VM-only boundary (ADR-13-B1)
The nightly run showed the in-container in-place upgrade scenario is the only one
that requires the harness to be a genuinely functional pod-scheduling cluster:
`kubeadm upgrade apply` preflight needs a Ready node (CNI) AND an
upgrade-health-check Job whose pod must schedule + complete. That property is the
least provider-specific (the provider just invokes kubeadm) and is already
validated on the libvirt VM upgrade smoke; forcing the minimal container to be a
functional data plane (hand-rolled CNI or a kindnet dependency) adds the most
fragility for the least signal.
Per ADR-13-B1 (staff-architect ratified), extend the VM-only upgrade coverage
boundary to include the kubeadm-layer in-place upgrade and drop the in-container
scenario. #4202's acceptance is met by (i) pre-membership failure-status and (ii)
multi-CP stacked-etcd HA in-container (both proven green), and (iii) the kubeadm
upgrade on the VM boundary.
- Remove test/e2e/nightly_upgrade_test.go and its exclusive helpers CopyInto +
extractBinariesFromImage from nodecontainer.go.
- nightly.yml: drop the higher-minor resolve + the two higher-minor image builds
and the E2E_UPGRADE_TO_* env; one base build per leg; timeout 150 -> 120.
- Makefile: drop the E2E_UPGRADE_TO_* knobs from e2e-nightly.
Re-verified after removal: HA scenario still PASSES end-to-end (2 CP nodes, 2 etcd
members); go vet -tags "e2e nightly" clean; failure-status + HA remain green.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: William Rizzo <william.rizzo@gmail.com>
0 commit comments