evetest: TestUpgradeSuite KVM→Kubevirt variants conflict with baseosmgr kvm↔k upgrade guard

[eriknordmark]

Summary

The TestUpgradeSuite variants added in #6083 that go KVM → Kubevirt (EVE-K) appear to conflict with an EVE-OS guard in baseosmgr that explicitly refuses kvm ↔ k base-OS upgrades. I don't think these variants can pass against upstream EVE as written, and one of them may go green for the wrong reason. Flagging before we wire evetest into CI and build the kvm→k migration test on top of this suite.

cc @milan-zededa

The guard

baseosmgr rejects an upgrade whenever the running image's personality differs from the target's — independent of disk size:

pkg/pillar/cmd/baseosmgr/handlebaseos.go (~L215):

// Check to avoid upgrading from not-EVE-k (e.g., kvm) to EVE-k
// and vice versa since that can result in odd failures due to
// different /persist layout etc.
// TBD Remove this if EVE-k in the future can have kvm personality.
isCurrentKube := base.IsHVTypeKube()
isUpdateKube, err := base.IsVersionHVTypeKube(config.BaseOsVersion)
...
} else if isCurrentKube != isUpdateKube {
    errString = "Upgrade to EVE-k (%s) from non EVE-k (%s) is not supported"  // or vice versa
    status.SetErrorNow(errString)
    return changed   // rejected in place — before install/activate, no partition write, no reboot
}

Documented in docs/EVE-K.md (§ Upgrades):

Upgrades of HV=k EVE-OS are supported through the existing interfaces. Upgrade from other HV= types is not supported and upgrade from HV=k to other HV= types is not supported.

Classification is by version string: IsVersionHVTypeKube takes the second-to-last --field of <rootfs>-<HV>-<ZARCH> and compares it to "k".

Why the variants trip it

UpgradeEVE → EVEDockerImageName correctly maps HV_KUBEVIRT → "k" (evetest/utils/docker.go), so it pulls the real <repo>:<ver>-k-<arch> image and the short version it reads back contains -k-. On a device currently running KVM, isCurrentKube=false / isUpdateKube=true → the guard fires and sets a BaseOsStatus error. A larger disk does not help, since the guard is personality-based, not size-based.

Consequences for tests/upgrade/testsuite_test.go:

• TestEVEUpgradeKVMtoKubevirt (expects success): waitForUpgrade should observe BaseOsStatus_FAILED (or time out) and Fatalf — i.e. it can't pass on upstream EVE.
• TestEVEUpgradeKVMtoKubevirtWithSmallDisk (expects revert): may report green for the wrong reason — reverting/failing because of the personality guard, not the intended insufficient-disk path. Also, the guard rejects in place with no reboot, while expectRevert pre-increments the expected reboot count by 2 — so there may be a reboot-count bookkeeping mismatch. (I haven't verified the reboot-count part.)
• KVMtoKVM, KubevirtToKubevirt, and KVMtoKVMWithSmallDisk (same-personality, plus a genuine size-driven revert) look self-consistent with upstream behavior.

Questions

1. Were the KVM→Kubevirt variants ever run green, and against what EVE build? (The PR checklist says "tested on amd64" without naming the variant.)
2. Is the intent that these presuppose the in-field kvm→k migration (repartition + lifting the TBD Remove this... guard)? If so, on what timeline?
3. Until the migration path exists, should these variants (a) assert that the upgrade is rejected as the expected outcome, or (b) be Skipped, so the suite doesn't carry a variant that can't pass?

Context

This came out of planning the migration of the update-dependent Eden escript tests (starting with update_eve_image, and ultimately the kvm→k migration test) onto evetest, and figuring out the evetest CI structure. Happy to send a PR for whichever direction you prefer on Q3.

Aside: EVE-K vs "kubevirt" naming

Minor/cosmetic, not the cause of the above: EVE renamed this flavor to EVE-K (HV=k; KubevirtHypervisorName = "k"), but evetest still uses "Kubevirt" throughout (HypervisorKubevirt, EVETEST_HYPERVISOR=kubevirt, the test names). Image resolution is correct, but the label can be confused with the in-cluster kubevirt component. Might be worth normalizing to k/EVE-K.

[milan-zededa]

I do not understand what this issue ticket is for. The kvm -> k upgrade support is a work-in-progress and of course will not work with the current EVE releases. Having the upgrade test fail for this combination is therefore expected for the time being.

Were the KVM→Kubevirt variants ever run green, and against what EVE build? (The PR checklist says "tested on amd64" without naming the variant.)

I left a comment there: #6083 (comment)