Repository navigation
π Explain why a scheduled hive upgrade window was held - #12061
Conversation
Every gate in triggerAutoUpgrades that turned away a daily/weekly hive while its window was open logged at Debug only, so a stable-channel hive that missed its 13:00 ET window kept showing the previous manual upgrade with no reason. Persist the hold reason on the hive record, relay it in the heartbeat upgrade policy, and render it in the spoke auto-update status and version menu. Refs #11196 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: scanner <scanner@hive.kubestellar.io> Co-authored-by: MikeSpreitzer <14296719+MikeSpreitzer@users.noreply.github.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
hive/awaiting-ci: CI pending β sweep will merge when green. π Hive Agent: β hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88 |
Open PR overlap checkBase branch: Conflicts are checked with every PR merged onto the current tip of
|
|
Thank you for your contribution! Your PR has been merged. We'd love to hear how your experience was: share feedback |
Gap
#11236 fixed stable promotion (stable now advances every ~15β60 min on v5 β verified in the Oct 14 promote-stable runs). The reopen is about the other half: the FMA hive (
:stable, hub-managed, daily window 13:00 ET) did not upgrade at 13:00 EDT Oct 14, and its dashboard still showed the 2026-10-14T03:30Z manual upgrade with no explanation.In
triggerAutoUpgrades, every gate that can turn away a daily/weekly hive after its window has opened β earlier upgrade latch still pending, digest pin, claim in flight, provisioning/error status, no reported commit, unresolved channel, merge debounce, no cluster config, undeliverable hive, full upgrade wave β only logged at Debug (or a hub-side Warn). Nothing reached the hive record, the heartbeat, or the spoke dashboard, so a skipped window could not be told apart from "the schedule never ran", and there was nothing for the reporter or a maintainer to act on.Fix
auto_upgrade_hold_reason/auto_upgrade_hold_at, written only when the reason changes, so a persistent hold costs one save). The hold clears when the hive is armed, reaches or passes its target, or its auto-upgrade setting is changed (single and bulk toggle).HeartbeatUpgradePolicyrelays it asscheduled_hold_reason/scheduled_hold_atfor hub-managed daily/weekly hives (mirrored in the spoke struct)./api/version.autoUpdategainsheldReason/heldAt, appended to the behind/unknown detail ("The scheduled update window opened but the hub held the upgrade at β¦: β¦"), and shown as aHeldrow in the version menu plus a line in the Hub-tab auto-update status (uses the existingtext-warnclass, no inline styles).release-channels.mdwaiting section; changelog fragment.Tests
pkg/hub/scheduled_upgrade_hold_test.go: window-open predicate, the real sweep records a held claim at 14:00 ET but not before the window or for a manual hive, persist/repeat/clear semantics, and heartbeat relay (daily/weekly yes; instant, disabled, nothing-held no).pkg/dashboard/autoupdate_status_test.go: held detail/JSON in behind state; cleared when up to date, paused or disabled; index.html renders the hold.Refs #11196 (needs-human: reporter must confirm the FMA hive upgrades at its next window after this ships)
β hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88 requested_by=@MikeSpreitzer