Closed
Description
Affected version
Yes. (Still an issue on trunk, introduced in #571, rolled out around SDP 23.4.)
Current and expected behavior
Reconciling a cluster where there nothing has changed should be a no-op.
ClusterCondition::last_update_time
breaks this expectation since it is set unconditionally to whatever the current time is, rounded to the second (
operator-rs/crates/stackable-operator/src/status/condition/mod.rs
Lines 350 to 355 in 61596d6
Possible solution
- Drop
last_update_time
completely (for compat: either stub it out or make it equivalent tolast_transition_time
) - Take the value from whenever the data source for the condition was updated, rather than the current wall time (if it makes sense/is possible for that condition)
Additional context
Discovered by @siegfriedweber, discussed at https://stackable-workspace.slack.com/archives/C02FZ581UCD/p1747230004370629
Environment
No response
Would you like to work on fixing this bug?
None
Metadata
Metadata
Assignees
Type
Projects
Status
Done
Activity
maltesander commentedon Jun 11, 2025
The approach back then was to follow the OpenShift
ClusterOperatorStatusCondition
, see https://github.com/openshift/api/blob/b1bcdbc3/config/v1/types_cluster_operator.go#L101.There, the
last_updated_time
does not even appear so i am not sure why it was introduced here, as this would always only be the last timestamp the operator reconciled, which does not provide much value.Suggestion is using Solution 1 and just drop it.