You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pkg: Use risk.Source framework to feed Upgradeable
This simplifies the complex cvo package by shifting some logic into
small, narrowly scoped helper packages. That makes for easier unit
testing of that logic, and less complication when reading the
remaining cvo package code.
Using the risk.Source framework with the new aggregate implementation
allows Upgradeable risks to feed into the conditionalUpdateRisks
framework. This should help reduce confusion some users experience
when the see Upgradeable=False and think it applies to all updates
(when in reality it applies to major and minor bumps, but does not
apply to patch updates, especially since 6f8f984, OTA-1860: Stop
blocking patch updates when cluster version overrides are set,
2026-02-10, #1314). It will also allow structured access to
individual risks that are reported via this pipeline, while
Upgradeable had an aggregated message string only consumable by
humans.
I'm also removing internal.UpgradeableAdminAckRequired and similar
from ClusterVersion status.conditions. While these were visible by
end users, they were mostly a mechanism for passing data from one part
of the CVO to another. There are no known consumers outside of the
CVO.
With the refactor providing clearer abstraction layers, I could drop
the entire upgradeableCheckIntervals structure. Major touches in the
history of that structure were bd05174 (pkg/cvo/upgradeable.go:
Sync Upgradeable status of the CVO more often, 2022-08-02, #808) and
cc94c95 (pkg/cvo/upgradeable: refactor throttling, 2023-01-11, #882).
The new approach is event-driven via the informer handlers for almost
all of the new risk.Source implementations. The one source that still
relies on polling is the deletion source, where it's watching a
CVO-side global variable, and not a Kube-side informer. It will still
sync whenever ClusterVersion status is updated though, which should be
often enough for this usually-transient situation. If folks want
lower latency, follow up work could add informer-style handler
callbacks to the deletion global.
The changeCallback in unit tests is unbuffered, because I want to know
exactly how often that callback is being called. If a logic change in
the packages causes additional callback calls, the unbuffered channel
will block them from sending the message, deadlock the informer for
that handler [1], and break later test-cases.
[1]: https://github.com/kubernetes/client-go/blob/v0.35.3/tools/cache/shared_informer.go#L1052-L1086
0 commit comments