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
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:
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.
Created: 3 weeks ago
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
2.6 registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest 3 weeks ago registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest 19c92ed464ccfaa085af8ed8c
latest 2.6 3 weeks ago registry.access.redhat.com/rhscl/mongodb-26-rhel7:latest 19c92ed464ccfaa085af8ed8c
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
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):
Steps to Reproduce:
1.mnetioned in the description
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:
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.
# 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.