Bug 1419801 - 'new-app' and 'new-build' should tolerate adding a tag to the existing imagestream
Summary: 'new-app' and 'new-build' should tolerate adding a tag to the existing images...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Build
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.8.0
Assignee: Gabe Montero
QA Contact: XiuJuan Wang
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-07 05:47 UTC by XiuJuan Wang
Modified: 2018-03-28 14:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: oc new-app/new-build code did not honor existing images streams when generating the list of objects to be created as part of processing a template; also, as part of processing input and output images, stack overflows as a result of circular references were possibly Consequence: Either imagestream already exists or stack overflow errors would occur on `oc new-app` or `oc new-build` Fix: code changes to the `oc new-app/new-build` paths were updated to looks for existing images streams and better deal with circular references Result: oc new-app/new-build work as expected.
Clone Of:
Last Closed: 2018-03-28 14:05:01 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0489 0 None None None 2018-03-28 14:05:44 UTC

Description XiuJuan Wang 2017-02-07 05:47:57 UTC
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:

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

#oc  new-build  ruby-ex:2.0 https://github.com/openshift/ruby-ex.git


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:

Comment 1 Ben Parees 2017-08-28 19:07:30 UTC
work in progress PR for this:

Comment 2 Ben Parees 2017-10-09 20:50:01 UTC
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.

Comment 3 Gabe Montero 2017-10-10 18:22:14 UTC
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:

  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.

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?

Comment 4 Ben Parees 2017-10-10 18:48:31 UTC
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

Comment 5 Gabe Montero 2017-10-12 18:44:19 UTC
New PR is https://github.com/openshift/origin/pull/16843

Comment 6 Gabe Montero 2017-11-10 19:21:54 UTC
Quick update: the PR has been marked for merge, just waiting for the 3.7 induced lockdown of openshit/origin:master to be lifted.

Comment 7 Gabe Montero 2017-11-14 14:22:44 UTC
PR merged .... moving to modified

Comment 9 XiuJuan Wang 2018-01-03 08:39:30 UTC
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
$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

Comment 11 Gabe Montero 2018-02-21 15:09:51 UTC
The fix has been verified by QE and is currently targeted for the 3.9 release.

Comment 14 errata-xmlrpc 2018-03-28 14:05:01 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.


Note You need to log in before you can comment on or make changes to this bug.