Greg Dubicki

Still valid! I just had to anonymize manually again in https://github.com/scylladb/scylla-operator/issues/2133.

/remove-lifecycle stale

/remove-lifecycle rotten

I am also seeing this in the `scylladb-api-status-probe` container logs of the Scylla pod: ``` I0712 14:17:47.251251 1 operator/cmd.go:21] maxprocs: Leaving GOMAXPROCS=[1]: CPU quota undefined I0712 14:17:47.251718 1 probeserver/scylladbapistatus.go:133] scylladb-api-status...

Also in the `scylla-operator` Deployment I am seeing this in the logs: ``` I0712 14:14:38.692544 1 scyllacluster/status.go:36] "Status updated" ScyllaCluster="scylla/scylla" I0712 14:14:48.696285 1 scyllacluster/status.go:29] "Updating status" ScyllaCluster="scylla/scylla" I0712 14:14:48.709939 1...

We are also seeing disk usage constantly growing on all the nodes since the update, although our cluster usage has not changed, but apart from that the cluster itself seems...

> > Scylla Operator from 1.9.x to 1.12.2 > > scylla operator only supports n+1 upgrades, otherwise you may miss a migration step Oh, got it now but I didn't...

How to fix this now, @tnozicka? Should I apply CRDs from the each version 1.10., 1.11., ..., 1.13. as documented in the 2nd step of https://operator.docs.scylladb.com/stable/upgrade.html#upgrade-via-helm?

> > Oh, got it now but I didn't do it this way as it was not documented at https://operator.docs.scylladb.com/stable/upgrade.html > > It only shows the X.Y.Z to X.Y+1.Z upgrades...

> > How to fix this now > > Rollback the operator deployment manifest an image back to where it started and follow the upgrade guide for each Y+1 from...