Skip to content

[WIP] baseosmgr: gate EVE-k vs non-EVE-k upgrade block on volumes - #5993

Closed
eriknordmark wants to merge 3 commits into
lf-edge:masterfrom
eriknordmark:baseos-hv-check-volume-gate
Closed

[WIP] baseosmgr: gate EVE-k vs non-EVE-k upgrade block on volumes#5993
eriknordmark wants to merge 3 commits into
lf-edge:masterfrom
eriknordmark:baseos-hv-check-volume-gate

Conversation

@eriknordmark

Copy link
Copy Markdown
Contributor

Description

The cross-flavor BaseOs upgrade between EVE-k and non-EVE-k flavors is
unconditionally rejected by baseosmgr with "Upgrade to EVE-k ... is
not supported" (or its inverse). The rationale is that the on-disk
/persist layout used by volumes differs across flavors, so existing
volumes can break across the switch. On a device with no volumes there
is nothing to disturb, so the block is overly strict.

This PR gates the check on volume presence:

  • baseosmgr subscribes to VolumeConfig (from zedagent) and
    VolumeStatus (from volumemgr). When either set is non-empty, the
    cross-flavor mismatch errors out as before — the error now reads
    ... is not supported while volumes exist. With both sets empty the
    upgrade proceeds.
  • A startup wait in baseosmgr blocks until both publications signal
    restart, so the first BaseOsConfig arrival after boot evaluates
    against the true volume set. Synchronized() is insufficient — it
    only confirms the socket-level handshake and can fire before zedagent
    has parsed its first EdgeDevConfig.
  • volumemgr now calls pubVolumeStatus.SignalRestarted() at the tail
    of handleVolumeRestart. After zedagent restarts pubVolumeConfig,
    volumemgr has reconciled its on-disk recovery
    (populateExistingVolumesFormat*) with the controller-intended set
    into VolumeStatus, so subscribers have a Restarted() gate to
    reason about.
  • Drive-by: pkg/pillar/types/diskmetrics_test.go used
    /persist/volumes/vol1 as a sample DiskPath; updated to
    /persist/vault/volumes/vol1 to match the canonical path
    (SealedDirName + "/volumes").

How to test and validate this PR

Same-flavor regression (covered by eden):

  • eden test ./tests/update_eve_image -e update_eve_image_oci — PASS
    locally (12 min).
  • eden test ./tests/update_eve_image -e update_eve_image_http — PASS
    locally (~10 min).
  • Both verify the new baseosmgr startup wait does not block the upgrade
    flow and BaseOsConfig is processed across reboots.

Cross-flavor relaxation (manual):

  • On a device with no app volumes, push a BaseOsConfig pointing at an
    EVE-k image from a running non-EVE-k image (or vice versa). The prior
    behavior errored out; the new behavior allows the upgrade.
  • Deploy an app with a volume and retry the cross-flavor upgrade — the
    block returns with the new wording.

Changelog notes

  • 16.0-stable: To be backported.
  • 14.5-stable: No, this is a behavior change, not a bug fix.
  • 13.4-stable: No, same reason.

Checklist

  • I've provided a proper description
  • I've added the proper documentation — operator-visible change is
    covered by the error-message text
  • I've tested my PR on amd64 device — eden update tests on amd64
    qemu
  • I've tested my PR on arm64 device — not tested
  • I've written the test verification instructions
  • I've set the proper labels to this PR — leaving to reviewers on
    mark-ready

eriknordmark and others added 3 commits May 27, 2026 13:31
After zedagent restarts pubVolumeConfig, volumemgr has reconciled its
on-disk recovery (populateExistingVolumesFormat*) with the controller-
intended set into VolumeStatus. Signal restart on pubVolumeStatus at the
tail of handleVolumeRestart so subscribers can use Restarted() as a gate
on the published set being in a known state, rather than Synchronized()
which only reflects the socket-level handshake.

Signed-off-by: eriknordmark <erik@zededa.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The cross-flavor BaseOs upgrade between EVE-k and non-EVE-k was
unconditionally rejected. The rationale is that /persist/vault/volumes
layout differs across flavors, so existing volumes can break across the
switch. On a device with no volumes there is nothing to disturb, so the
block is overly strict.

Subscribe to VolumeConfig (from zedagent) and VolumeStatus (from
volumemgr) in baseosmgr and only error out on the flavor mismatch when
either set is non-empty. Wait at startup for both publications to signal
restart so the first BaseOsConfig after boot evaluates against the true
volume set; Synchronized() is not sufficient because it only confirms
the socket handshake.

Signed-off-by: eriknordmark <erik@zededa.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Test sample DiskPath used /persist/volumes/vol1; canonical path under
SealedDirName is /persist/vault/volumes. Update so the test exercises a
realistic value.

Signed-off-by: eriknordmark <erik@zededa.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@github-actions
github-actions Bot requested review from OhmSpectator and europaul May 27, 2026 17:29
@codecov

codecov Bot commented May 27, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 51 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.09%. Comparing base (324bd3c) to head (5b239d4).

Files with missing lines Patch % Lines
pkg/pillar/cmd/baseosmgr/baseosmgr.go 0.00% 44 Missing ⚠️
pkg/pillar/cmd/baseosmgr/handlebaseos.go 0.00% 5 Missing ⚠️
pkg/pillar/cmd/volumemgr/handlevolume.go 0.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #5993      +/-   ##
==========================================
+ Coverage   20.68%   21.09%   +0.40%     
==========================================
  Files         491      501      +10     
  Lines       90599    92345    +1746     
==========================================
+ Hits        18744    19479     +735     
- Misses      70274    71105     +831     
- Partials     1581     1761     +180     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@eriknordmark eriknordmark changed the title baseosmgr: gate EVE-k vs non-EVE-k upgrade block on volumes [WIP] baseosmgr: gate EVE-k vs non-EVE-k upgrade block on volumes Jun 10, 2026
@eriknordmark

Copy link
Copy Markdown
Contributor Author

Superseded by #6036 (baseosmgr volume-gate + upgradeconverter ns port + volumemgr transitive blob walk, rebased onto master) and #6035 (diskmetrics test path fix). Closing this WIP.

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