-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
4.20
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
co/csi-snapshot-controller reported Progressing=True only for a node reboot which should not happened during a normal cluster upgrade.
: [Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should stay Progressing=False while MCO is Progressing=True expand_less 1h5m35s
{ 2 (out of 7) unexpected clusteroperator state transitions while machine-config is progressing during the upgrade window from 2025-11-04T20:56:03Z to 2025-11-04T22:01:38Z. These did not match any known exceptions, so they cause this test-case to fail:
Nov 04 21:49:31.930 W clusteroperator/console condition/Progressing reason/SyncLoopRefresh_InProgress status/True SyncLoopRefreshProgressing: changes made during sync updates, additional sync expected
Nov 04 21:49:31.930 - 36s W clusteroperator/console condition/Progressing reason/SyncLoopRefresh_InProgress status/True SyncLoopRefreshProgressing: changes made during sync updates, additional sync expected
0 unwelcome but acceptable clusteroperator state transitions while machine-config is progressing during the upgrade window from 2025-11-04T20:56:03Z to 2025-11-04T22:01:38Z, as desired.}
Version-Release number of selected component (if applicable):
The example job does an upgrade to 4.21.0-0.nightly-2025-11-03-191704 from 4.20.0-0.nightly-2025-10-30-114955
How reproducible:
Seems quite often for 4.20 - 4.21 upgrades (Only detected on BareMetal)
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
co does not go Progressing=True only for a node reboot
Additional info:
- clones
-
-
- POST
-
- is duplicated by
-
-
- New
-
- relates to
-
OTA-1637 Fail CI if any Cluster Operator reports Progressing=True only up to cluster scaling or a node rebooting
-
- Closed
-
- links to