Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
This project is now read‑only. Starting Monday, February 2, please use https://ibm-ceph.atlassian.net/ for all bug tracking management.

Bug 1944228

Summary: Avoid upgrade on same image or version
Product: [Red Hat Storage] Red Hat Ceph Storage Reporter: Sunil Kumar Nagaraju <sunnagar>
Component: CephadmAssignee: Adam King <adking>
Status: CLOSED ERRATA QA Contact: Sunil Kumar Nagaraju <sunnagar>
Severity: high Docs Contact: Karen Norteman <knortema>
Priority: unspecified    
Version: 5.0CC: adking, jolmomar, sewagner, tserlin, vereddy
Target Milestone: ---   
Target Release: 5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ceph-16.1.0-1084.el8cp Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-08-30 08:29:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 3 Adam King 2021-04-05 15:47:55 UTC
@Sunil While it is possible for the actual image behind the "latest" tag to change over time (which is part of why we check always check the image during upgrade even if it's the same repo + tag as the cluster is already using) it should not be possible for the cluster to end up with multiple different images after upgrade, even if the image specified by the tag we are using was to be altered mid upgrade. That's because we always convert the image name to a repo digest as part of the upgrade. While the tag name can represent different versions of an image over time, the digest will be unique to a specific build of an image. By using the digest rather than image tag name while upgrading we guarantee that every daemon has exactly the same image when the upgrade is complete, not just that they all have an image with the same tag name.

If you had a situation where the image behind the tag the cluster was using had changed and you also had new daemons with a different image completely (not even the same tag) and then upgraded to remedy the situation, all the daemons, even those already on the right tag, would be upgraded to the last version of the image behind the tag. In the end all the daemons would be using identical images.


Also, while images with tags other than latest (I'm assuming you're thinking of tags that represent stable releases) should be static and in theory we would not need to check the image to see if it has changed and just immediately bail out of upgrade, it would be difficult to determine just based on the tag that this image is one meant to be static (there are tags other than latest that can be for transient images) and we would need to have 100% faith that whoever is upkeeping the image has kept their promise and not updated it. Ultimately, it's much simpler to just pull the image and check it ourselves than to worry about such things. Especially given that the process should be very quick if it turns out no daemons actually need to be upgraded.

Comment 4 Juan Miguel Olmo 2021-04-06 14:42:01 UTC
@Sunil: can you review the Adam's answer and verify if we can close this bug?

Comment 8 errata-xmlrpc 2021-08-30 08:29:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat Ceph Storage 5.0 bug fix and enhancement), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:3294