Description of problem: Seeing some clusters with type="updating",from_version=X,version=X: {_id="1b1eb908-c095-4a94-bc7c-4bde7942af7a", from_version="4.1.41", type="updating", version="4.1.41"} Ref: https://coreos.slack.com/archives/CEGKQ43CP/p1600260341388300 And more details and example clusters linked here: https://issues.redhat.com/browse/SDA-2743 Duplicate entiries should not be in version history but will check if there is a bug in the merge logic.
Even if fixed in CVO I assume this is too minor to deserve backporting, so we'll still see those in telemetry for a long time. Externally visible impacts: - [x] The OCM UI https://cloud.redhat.com is hiding such upgrades. - [ ] The API api.openshift.com is reporting X->X upgrades when present in telemetry. Do you think we should filter them, or just leave it as is, until eventually fixed?
Sprint is up, but we want to fix this. Hopefully next sprint.
Upgrading from/to the same version, and having in history, happens when the "--to-image" to upgrade to differs in any way from the currently loaded image, e.g. different repo or using "<repo>:semvar" vs. "<repo>@digest". For example, a cluster at 4.5.16 with image "registry.svc.ci.openshift.org/ocp/release@sha256:adb5ef06c54ff75ca9033f222ac5e57f2fd82e49bdd84f737d460ae542c8af60": - upgrade will occur for `--to-image quay.io/openshift-release-dev/ocp-release:4.5.16-x86_64` - from there `--to-image quay.io/openshift-release-dev/ocp-release@sha256:adb5ef06c54ff75ca9033f222ac5e57f2fd82e49bdd84f737d460ae542c8af60` results in another upgrade - the same image in the same repo but referenced by `4.5.16-x86_64` vs. digest or vice-versa results in an update However using `--to 4.5.16` is blocked by oc client with "Cluster is already at version 4.5.16".
Any changes to the image will require the upgrade logic to run. Since I can only recreate this issue by making the from/to image differ as described in comment https://bugzilla.redhat.com/show_bug.cgi?id=1879963#c3, closing this as not a bug.