Created attachment 1145026 [details]
screenshot when I access to the console first
Description of problem:
- On screen "Select Image or Template", latest stream version is hidden.
Version-Release number of selected component (if applicable):
- OSE v188.8.131.52 (xpaas 1.2)
Steps to Reproduce:
1. Go webconsole
2. Push Add to project
3. You can see "jboss-eap64-openshift:1.1", but you can NOT see "jboss-eap64-openshift:1.2" by default
NOTE: if you use "See all", you can see 1.2 as well.
- Most of the user select "jboss-eap64-openshift:1.1" due to the hidden 1.2 stream.
- show latest image (in this case "jboss-eap64-openshift:1.2"), and hide previous versions by default.
- Attached screen shot.
- jboss-eap64-11.png is the screenshot when I access to the console first.
- after-see-all.png is the screen shot after I pushed "See all".
Created attachment 1145027 [details]
screenshot after I pushed "See all"
We need the change from the API that's been discussed where the API will return tags ordered by semantic version.
TODO for PM side: Update the image stream api to return tags ordered by semantic version.
I've changed how tags in status are sorted, I hope that will suffice. See https://github.com/openshift/origin/pull/9606
Commits pushed to master at https://github.com/openshift/origin
Bug 1325069 - Sort status tags according to semver
Merge pull request #9606 from soltysh/bug1325069
Merged by openshift-bot
Check against v184.108.40.206
Now installed image stream jboss-eap64-openshift has four tags:1.1,1.2,1.3 and 1.4
After initial load, jboss-eap64-openshift:1.1 jboss-eap64-openshift:1.2 jboss-eap64-openshift:1.3 will be shown in list, latest jboss-eap64-openshift:1.4 is not shown until click "See all"
Seems latest image stream is still hidden
Created attachment 1187359 [details]
Created attachment 1187360 [details]
Jessica which information you're looking at spec or status? I've currently fixed status which returns tags in aforementioned semantic version order like so (cut the output for brevity):
$ oc get is/python -n openshift -o yaml
- name: "2.7"
- name: "3.3"
- name: "3.4"
- name: "3.5"
- name: latest
- tag: latest
- tag: "3.5"
- tag: "3.4"
- tag: "3.3"
- tag: "2.7"
We use status, I suspect we are messing up the sort order somewhere in the console code, I'll reassign this and we will take a look.
merging to origin in https://github.com/openshift/origin/pull/10253
sorry forgot this was an OCP bug, leaving as assigned to origin PR merges
Checked against v220.127.116.11,
For xpaas images, it didn't show which image is latest
Take jboss-eap64-openshift as example
# oc get is/jboss-eap64-openshift -n openshift -o yaml
jboss-eap64-openshift:1.4 is the latest image, this should be identified on web console
Created attachment 1190255 [details]
Attachment PythonWithLatestWord shows Python:3.5 is latest image
Created attachment 1190256 [details]
In attachment JbossEAP64BeforeSeeAll, jboss-eap64-openshift:1.4 was not indicated as latest image where should be
The JBoss image streams have no :latest tag. The console will only show latest for image streams that have a :latest tag which references another tag in the same stream.
(In reply to Samuel Padgett from comment #20)
> The JBoss image streams have no :latest tag. The console will only show
> latest for image streams that have a :latest tag which references another
> tag in the same stream.
Sorry please disregard. I was looking at the wrong image stream.
OK, I believe I see the problem. There is a status tag latest, but no spec tag latest. Since the `from` definition is on the spec tag, we can't mark 1.4 latest in the web console. See
Here's an example of an image stream with a latest spec tag.
Even if we look at status tags, there is no way we can know what :latest tracks without the spec. So the web console is behaving as I'd expect, and the image stream needs to be updated if we want that behavior for the JBoss builder images.
Samuel, thanks for your explanation, I got what you mean.
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.