[james-nesbitt]

What

Three smoke suites gain an MSR node, so that launchpad's MSR install path is exercised for the first time:

Suite	MSR node	MSR version
TestModernCluster	ubuntu24	2.9.28 (was 3.1.18)
TestUpgradeLegacyToModern	ubuntu22	2.9.28 → 2.9.30
TestUpgradeModernClusterFromLegacy	ubuntu24	2.9.28 → 2.9.30

One m6a.2xlarge per run each.

Why

test/platforms.go:37 has defined GetMSR() with zero callers. Every smoke suite set MSRVersion, and smoke_test.go:110 passed it to terraform as msr_version, but examples/terraform/aws-simple/launchpad.tf:207 derives has_msr by counting msr-role nodegroups:

has_msr = sum(concat([0], [for k, ng in local.nodegroups : ng.count if ng.role == local.launchpad_role_msr])) > 0

With no GetMSR() call that is always false, so :231 rendered kind: mke rather than kind: mke+msr, and the :273-281 block that emits spec.msr was skipped. msr_version travelled the whole way and was discarded at the last gate. launchpad.tf:20 documents the field as "unused if you have no MSR hosts".

No smoke test has ever installed MSR, on any suite, for either 2.x or 3.x — while eight configurations read as though they covered it. smoke-legacy in particular looks like it covers MSR 2.9.28 and does not. That appearance has already misled one review into crediting MSR coverage that did not exist.

This is a property of main; no open PR introduced it.

TestModernCluster's version moves 3.1.18 → 2.9.28

The terraform renders MSR 2.x only: kind: mke+msr with --dtr-external-url and --ucp-insecure-tls. This launchpad has no MSR 3 support at all — no msr3 kind anywhere in pkg/, and the MSR phases are DTR-era.

So 3.1.18 would have produced a kind: mke+msr document carrying a 3.x version. Nothing caught it because the block was never rendered.

Upgrading MSR

bumpVersions now takes an msrVersion and rewrites spec.msr.version beside the MCR channel and MKE version, so the upgrade suites move MSR as part of the same in-place upgrade.

• an empty msrVersion leaves the document alone — the correct shape for a cluster with no MSR node
• a non-empty one against a document with no spec.msr is reported, not silently skipped: that combination can only be a configuration mistake

2.9.30 is the newest mirantis/dtr 2.9.x tag on Docker Hub, checked against the registry.

Testing

• bumpVersions exercised offline against both document shapes: versions replaced; --san, --dtr-external-url and host addresses preserved verbatim; the no-MSR cluster untouched; the mismatch rejected. Throwaway, not committed.
• go vet ./test/... and gofmt -l test/: clean
• Not yet run: the smoke jobs themselves — that is what the labels on this PR are for

Known unknowns

Both need a real run to settle, and neither is answerable from the repo:

• Whether MSR 2.9.x installs against MKE 3.9.2 at all. The upgrade suites already declared that pairing, but it has never executed. If MSR 2.x support was dropped in MKE 3.9, TestModernCluster is where that surfaces.
• Whether GetMSR()'s m6a.2xlarge is sized for MSR. It matches GetManager(), presumably deliberately, but nothing has ever run on it.

A failure in either direction is new information, not a regression.

Checklist

• Tests added or updated
• Docs updated if user-visible behaviour changed (N/A — test-only)
• No debug output or dead code left in

Written by AI: claude-opus-5