test(e2e): drop in-container kubeadm upgrade scenario; VM-only boundary (ADR-13-B1)#27
Merged
Merged
Conversation
…ry (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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Follow-up to #26. The first nightly (
workflow_dispatch) run showed thein-container kubeadm-layer upgrade scenario fails, while failure-status, HA,
and all Tier-1 scenarios pass. #26 merged before this fix could be added, so
mainstill carries the failing scenario — this PR removes it.
Per ADR-13-B1 (staff-architect ratified), the VM-only upgrade coverage
boundary is extended to the kubeadm-layer in-place upgrade, and the in-container
scenario is dropped.
Why
kubeadm upgrade applypreflight requires a genuinely functional pod-schedulingcluster: a Ready node (needs a CNI) and an
upgrade-health-checkJobwhose pod must schedule + get a working sandbox + complete. The minimal
host-networked harness has no CNI (init/join/HA/failure don't need pod scheduling).
That functional-cluster property is the part least specific to the provider
(the provider just invokes
kubeadm upgrade apply), and the upgrade is alreadyvalidated on the libvirt VM upgrade smoke. Making the container a functional data
plane (hand-rolled CNI, or a kindnet image dependency) adds the most fragility for
the least provider-specific signal.
#4202's acceptance is met by: (i) pre-membership failure-status in-container,
(ii) multi-CP stacked-etcd HA in-container (both proven green in the nightly and
locally), and (iii) the kubeadm upgrade on the VM boundary.
Changes
test/e2e/nightly_upgrade_test.goand its exclusive helpersCopyInto+extractBinariesFromImage(nodecontainer.go).nightly.yml: drop the higher-minor resolve + the two higher-minor image buildsand the
E2E_UPGRADE_TO_*env; one base build per leg;timeout-minutes150→120.Makefile: drop theE2E_UPGRADE_TO_*knobs frome2e-nightly.Validation
HA re-verified green end-to-end after the removal (2 CP nodes, 2 etcd members);
go vet -tags "e2e nightly"clean;nightly.ymlvalid, actions SHA-pinned.