Hide Forgot
Description of problem: When add a tag to the existing imagestream, 'new-app' and 'new-build' should respect this situation Version-Release number of selected component (if applicable): oc v3.5.0.17+c55cf2b How reproducible: always Steps to Reproduce: 1.Use same name for input and output image, but different tag #oc new-app ruby-ex:2.0 https://github.com/openshift/ruby-ex.git 2.‘new-build’ #oc new-build ruby-ex:2.0 https://github.com/openshift/ruby-ex.git 3. Actual results: Will prompt error. #oc new-app ruby-ex:2.0 https://github.com/openshift/ruby-ex.git --> Creating resources ... error: imagestreams "ruby-ex" already exists Expected results: Should tolerate adding a tag to the existing imagestream Additional info:
work in progress PR for this: https://github.com/openshift/origin/pull/13848
Gabe, the above PR got this pretty far along but has probably bit-rotted, you may just want to review it to get an idea of the direction Ryan was headed in with it. The general idea is that if new-app is going to create an imagestream name that already exists, it should instead just create a tag within that imagestream.
Ben - first, just noting I had to change the repro steps here slightly to see anything like this, and still have a few questions. 1) If I literally tried `oc new-app ruby-ex:2.0 https://github.com/openshift/ruby-ex.git` I got: error: Errors occurred while determining argument types: ruby-ex:2.0 as a Git repository URL: ssh: Could not resolve hostname ruby-ex: Name or service not known fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ruby-ex:2.0 as a local directory pointing to a Git repository: stat ruby-ex:2.0: no such file or directory Errors occurred during resource creation: error: no match for "ruby-ex:2.0" 2) thinking the images streams might have changed names, I then ran `oc new-app --list` and saw this for ruby: ruby Project: openshift Tags: 2.2, 2.3, 2.4, latest so I switched to `oc new-app ruby:2.2 https://github.com/openshift/ruby-ex.git` and that worked successfully. 3) I then tried `oc new-app ruby:2.3 https://github.com/openshift/ruby-ex.git` and it complained about ruby-ex existing. Questions: a) is this the intended flow? ... the PR also denotes a slightly different permutation, though I think it results in the same root cause/effect b) the new-app in 3) also complained about duplicate buildconfigs. deploymentconfigs, and services ... I saw some discussion of this with Clayton in the PR, but am not sure I saw a consensus reached ... where do you want the initial stake in the new PR to be? ... more general/holistic, or image specific?
a) yes. I think the recreate may have left out a step, or used the wrong name, but your recreate shows the issue. b) image specific. Namely, that if the imagestreamtag we are about to try to create, already exists and points to the same place as the one we are about to try to create, then it's ok not to create it. And if the imagestream exists, but not the tag, it's ok to create the tag within the imagestream instead of failing because we can't create the imagestream. The critical problem to solve here is the one described in https://github.com/openshift/origin/issues/13169
New PR is https://github.com/openshift/origin/pull/16843
Quick update: the PR has been marked for merge, just waiting for the 3.7 induced lockdown of openshit/origin:master to be lifted.
PR merged .... moving to modified
1.Create a is $oc import-image ruby-ex:test --from='openshift/ruby-22-centos7' --confirm 2.Create app which will create above same is $oc new-app ruby:2.3 https://github.com/openshift/ruby-ex.git or $oc new-build ruby:2.3 https://github.com/openshift/ruby-ex.git same imagestream with different tag will be create successfully 3.Check is oc get is NAME DOCKER REPO TAGS UPDATED ruby-ex docker-registry.default.svc:5000/xiu1/ruby-ex latest,test 18 seconds ago Verified this bug in openshift cluster & client v3.9.0-0.9.0
The fix has been verified by QE and is currently targeted for the 3.9 release.
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-2018:0489