Closed zcross closed 1 year ago
Let's close this if the build with #1188 passes? I'm not sure how deterministic it is to repro, but one thing worth trying is just bringing up a fresh installation and seeing if that reproduces on 0.21.2
– then trying again with 0.21.3
Edit: #1189 fixes this w/ compiling code :)
@zcross , this is fixed in 0.21.3
Thank you!
@zcross , this is fixed in 0.21.3
@alex-zaitsev
Would it be possible to cut a release tag for 0.21.3
to distribute this fix?
I recently observed this on
0.21.2
while bootstrapping a brand new installation. FWIW, it was "self healing" after a few minutes: ongoing reconciliation operations seemed to bring the installation(s) into a state that caused the status to no longer be nil.https://github.com/Altinity/clickhouse-operator/blob/32ef0fadc3d07884845a1ee3d91be6b6e112ac62/pkg/apis/metrics/exporter.go#L295
My guess is that we can fix this by changing the access of
chi.Status.NormalizedCHICompleted
tochi.EnsureStatus().GetNormalizedCHICompleted()
, or something like that. I can't do it right this moment, but I'll circle back to this issue when I get some bandwidth.To generalize: maybe we want to use Golang visibility to make raw/unsynchronized fields on
Status
package-internal to more strongly encourage usage of safe public getter/setter APIs. I considered this in #1119 but IIRC, this resulted in problems when trying to deserialize/serialize the state ofStatus
(because it relied on field visibility)... I think?