Hide Forgot
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:
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
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.
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?
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. :)
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.
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