Bug 1328392

Summary: Unclear process for getting image updates.
Product: OpenShift Container Platform Reporter: Miheer Salunke <misalunk>
Component: Cluster Version OperatorAssignee: Scott Dodson <sdodson>
Status: CLOSED ERRATA QA Contact: liujia <jiajliu>
Severity: low Docs Contact:
Priority: medium    
Version: 3.1.0CC: aos-bugs, bleanhar, dherrman, erich, jokerman, mamburn, misalunk, mmccomas, sgraf, smunilla, sreber, tbielawa
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-04 10:40:18 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:

Description Miheer Salunke 2016-04-19 09:53:18 UTC
Description of problem:

Based on the documentation (https://docs.openshift.com/enterprise/latest/install_config/upgrades.html#updating-the-default-image-streams-and-templates) it is not clear as to what the process is for getting the information about newly available image upgrades. While being subscribed to get information about bug fixes and security advisories, I am not receiving any information about new OpenShift base images. E.g.  I just did oc import-image -n openshift jboss-webserver30-tomcat8-openshift, and received updates without having been aware that updates are available:
1.1                     4 weeks ago     registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat8-openshift:1.1
1.1-3   <pushed>        4 weeks ago     registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat8-openshift:1.1-3
1.1-7   <pushed>        4 weeks ago     registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat8-openshift:1.1-7
1.2                     4 weeks ago     registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat8-openshift:1.2
1.2-10  <pushed>        4 weeks ago     registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat8-openshift:1.2-10
latest  <pushed>        4 weeks ago     registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat8-openshift:latest

Also, If I don't want to introduce old versions (because I know that I have moved all my applications off these old version), I don't want to be getting updates for the old ones (like for
1.1-3
1.1-7
above). How can this be achieved?


Also it seems that Tags are now imported selectively, so only if you use the old "spec.dockerImageRepository" field do you import everything.  The tools are now upgraded to selectively import in almost all cases.It would be nice to have oc import-image accept --dry-run and show the difference, but no one has done it yet.

But then how can I "selectively import" ? I don't find any documentation on this, also not in oc --help. Where can I define a "tag"?

Also on this topic, https://rhn.redhat.com/errata/RHBA-2016-0350.html?sc_cid=701600000006NHXAA2 mentions 
that one should upgrade a variety of images. E.g, for mongo db, as far as I can tell, the image still has the same label:
     openshift3/mongodb-24-rhel7:2.4
Would we not expect for the version to bumped up?
If we changed an image and did not change the tag then we have failed somewhere in our release management process. 
 If I do
     oc import-image mongodb,
... I get:
Waiting for the import to complete, CTRL+C to stop waiting.
The import completed successfully.

Name:                   mongodb
Created:                3 weeks ago
Labels:                 <none>
Annotations:            openshift.io/image.dockerRepositoryCheck=2016-03-07T09:48:40Z
Docker Pull Spec:       172.30.x.y:5000/openshift/mongodb

Tag     Spec                                                            Created         PullSpec                                                Image
2.4     registry.access.redhat.com/openshift3/mongodb-24-rhel7:latest   3 weeks ago     registry.access.redhat.com/openshift3/mongodb-24-rhel7:latest   05cbfa57713479f0e4a52f560
cacb69ee31dc2241ddb9bec3d1461fbd616e17d
2.6     registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest        3 weeks ago     registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest        19c92ed464ccfaa085af8ed8c
ca18edfa242c337c9fcab6c9c7dd8b5cb2b9c3c
latest  2.6                                                             3 weeks ago     registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest        19c92ed464ccfaa085af8ed8c
ca18edfa242c337c9fcab6c9c7dd8b5cb2b9c3c

How can I tell now that I am up to date? Since this view only tells me "latest", and no specific version, how can I determine what the latest version is?

Eg- Here you have three tags for this image:
2.4, 2.6, latest
Looking further, "latest" appears to point at "2.6"
Unless the image itself has some kind of release notes, there is no way to understand or know what the tag actually means. Does 2.6 mean MongoDB 2.6? Does it mean something else?
Judging from the image name (mongodb-26-rhel7) my guess is that the 2.6 tag is a poor choice. We should either be tagging with a z (eg: 2.6.z) or we should be using a "build" string in our tag (eg: 2.6-1, -11, whatever).


Also, since it indicates "3 weeks ago", it looks like no patch has been installed (since "drown" is younger then that).
Here I think you would have to check with the SCL team to understand if they have released a patched version of the image. However if we have released an RPM errata for DROWN and we still haven't released images, that, again, seems like a huge problem. 

3 weeks ago seems to be the time that the image stream was created in this
instance OpenShift. It does not refer to the date that the image the
stream refers to was created.The mongodb ImageStream has three tags, latest, 2.4, and 2.6. latest points at 2.6 currently.
The 2.4 and 2.6 tags of the ImageStream refer to
registry.access.redhat.com/openshift3/mongodb-24-rhel7:latest and
registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest respectively.
I don't know of a good way to work towards answering 'Am I affected by
DROWN?' by only looking at ImageStreams or Images, nothing seems to
indicate the date of the repository tag it's referring to.
Though it seems you can look at the age of the image by running "oc describe
imagestreamtag/mongodb:2.4".  It will also print metadata included by
RCM into the image.

Would you not agree that the 2.6 tag is violating best practices, and in that sense, your "release management process" has failed?
What would you suggest we do to get this improved?

It is still very much not clear to me what the answer on my original question is:
 "How can I tell now that I am up to date?" 
Checking out the age of the image cannot be the solution for this.

Also, I would like to understand what new tags are given for new releases of the OpenShift image.s E.g. if we have an image with tag 2.4, what will be the tag if the image is released as a new bug fix release?


Version-Release number of selected component (if applicable):
3.1.1

How reproducible:
Always

Steps to Reproduce:
1.mnetioned in the description
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Brenton Leanhardt 2016-04-20 13:34:26 UTC
Talking with Stanislav a little bit ago I think the best solution we have today is for customer to subscribe to errata notifications for their products:

https://access.redhat.com/solutions/135503

Comment 9 Dirk Herrmann 2016-08-24 18:02:01 UTC
We've had a good meeting last Wednesday. I've shared the mid- and long-term vision around many items mentioned in this BZ. It seems that we will address most of them over time but not immediately. We've scheduled a follow-up mid of September to review if we will cover all aspects or not.

Comment 21 liujia 2019-01-31 03:03:53 UTC
Change status back to MODIFIED since we did not hit 4.0 Beta 2 now.

btw, how should QE verify this bug in v4.0? Does we should verify an cluster upgrade functionally or verify it through document process?

Comment 22 Brenton Leanhardt 2019-01-31 14:08:05 UTC
I believe 4.0 beta 2 will be upgradeable to beta 3.  I'm certain we'll give QE docs on how to do that when the time comes if it's not obvious from the UI.  In the worst case it will involve editing the clusterversion custom resource to trigger the process.   Once we GA the admin console should have a button to upgrade everything. :)

Comment 25 liujia 2019-04-15 08:17:24 UTC
Install a beta3 cluster.
# oc get clusterversion
NAME      VERSION     AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.9   True        False         15m     Cluster version is 4.0.0-0.9

Access the OpenShift web-console.
In [Administration]-[clustersettins] page, there are "update now" button for users to check available update list, and do upgrade directly.

Choose "4.0.0-0.11" (Beta 3 patch 2) in above list, and do upgrade. Then you can monitor the "update status" in the same page. Some info as fllowing shown:
Cluster update in progress. Working towards 4.0.0-0.11: downloading update. View Cluster Operators for more details.
Cluster update in progress. Working towards 4.0.0-0.11: 11% complete. View Cluster Operators for more details.
...

Upgrade succeed.
# oc get clusterversion
NAME      VERSION      AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.11   True        False         2m22s   Cluster version is 4.0.0-0.11

According to comment 18&comment22, in 4.x, now there is clear information about available update list and the cluster update status from UI. So verify the bug.

Comment 27 errata-xmlrpc 2019-06-04 10:40:18 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, 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-2019:0758