Bug 1304109 - oc new-app fail when creating a application from a imagestream
oc new-app fail when creating a application from a imagestream
Status: CLOSED CURRENTRELEASE
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
3.1.0
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Michal Fojtik
Wei Sun
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-02 17:14 EST by Ricardo Alonso
Modified: 2016-09-07 17:07 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-07 17:07:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ricardo Alonso 2016-02-02 17:14:53 EST
Description of problem:
Having two different projects (dev and prod), should be possible to promote an application built using S2I on dev to be used on prod without having to rebuild it from source. The basic procedure should be refer to the image generate on the internal registry and tag it with a different value (:prod for example).

When creating the application with the command it works fine, but the trigger is not created: 
(on the project prod)
[root@node ~]# oc new-app 172.30.103.87:5000/dev/php-helloworld:prod

Another way more interesting whould be using "oc tag..." to generate the image stream and use "oc new-app <is>" to create the application:

[root@node ~]# oc tag 172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4 hello-prod:latest
Tag hello-prod:latest set to 172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4.

[root@node ~]# oc describe is
Name:			hello-prod
Created:		15 seconds ago
Labels:			<none>
Docker Pull Spec:	172.30.103.87:5000/prod/hello-prod

Tag	Spec														Created	PullSpec	Image
latest	172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4<not available>	<not available>

But when I try to create the app, this is the result: 

[root@node ~]# oc new-app hello-prod
error: component "hello-prod" had only a partial match of "hello-prod" - if this is the value you want to use, specify it explicitly

Version-Release number of selected component (if applicable):
atomic-openshift.x86_64                              3.1.1.6-1.git.0.b57e8bd.el7aos       @rhel-7-server-ose-3.1-rpms
atomic-openshift-clients.x86_64                      3.1.1.6-1.git.0.b57e8bd.el7aos       @rhel-7-server-ose-3.1-rpms
atomic-openshift-master.x86_64                       3.1.1.6-1.git.0.b57e8bd.el7aos       @rhel-7-server-ose-3.1-rpms
atomic-openshift-node.x86_64                         3.1.1.6-1.git.0.b57e8bd.el7aos       @rhel-7-server-ose-3.1-rpms
atomic-openshift-sdn-ovs.x86_64                      3.1.1.6-1.git.0.b57e8bd.el7aos       @rhel-7-server-ose-3.1-rpms
atomic-openshift-utils.noarch                        3.0.35-1.git.0.6a386dd.el7aos        @rhel-7-server-ose-3.1-rpms


How reproducible:
Always

Steps to Reproduce:
1. Create two projects (dev & prod)
2. Create a new application from source in dev project
3. Tag the image generated from project dev as "prod" on docker
    # docker tag <image_id> <internal_docker>:5000/dev/<app-name>:prod
4. Create an imagestream on prod project referencing the tag :prod
    # oc tag <internal_docker>:5000/dev/<app-name>:prod <app-name>:latest
5. Create a new app on prod project using the imagestream:
    # oc new-app <app-name> 

Actual
error: component "hello-prod" had only a partial match of "hello-prod" - if this is the value you want to use, specify it explicitly results:


Expected results:
Application successfully created.

Additional info:
Instead of using docker to tag the image (that requires access to the enviroment shell), should be possible to using the docker url available on the IS description: 
172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4
Comment 1 Dan Mace 2016-02-03 08:41:36 EST
Reassigning to the CLI component.
Comment 2 Ben Parees 2016-02-03 15:50:12 EST
Michal you're most familiar w/ the current and coming soon behavior regarding promotion via tagging, can you take this?
Comment 3 Michal Fojtik 2016-02-04 03:41:06 EST
Ricardo Alonso:

I was recently playing with this and there is a change to internal Docker registry to allow this flow. The way that works for me is following:

$ oc new-project stage
$ oc new-project prod

$ oc create -f sample-app.json -n stage (create DeploymentConfig, BuildConfig and sample-app ImageStreams)
$ oc create -f sample-app.json -n prod (create the same as above except BuildConfig)

Now You start the build in stage:

$ oc start-build sample-app -n stage --wait --follow

This will produce following ImageStreamTag: "stage/sample-app:latest".
Now if if want to have this image tagged for production, you can use following command:

$ oc tag stage/sample-app:latest prod/sample-app:latest

This will create an ImageStreamTag "sample-app:latest" in "prod" project. Also the "prod" project need to have access to "stage" project, because the image referenced in "prod" will be still "stage" (there is an issue opened for this:
https://github.com/openshift/origin/issues/6924#issuecomment-178107498

However, don't worry that you are using the same image, in Docker registry the tag is set to a SHA256 ;-) So this is only cosmetic issue imho.

To allow pulling the image in "prod" you have to run this command:

$ oc policy add-role-to-user edit system:serviceaccount:prod:default -n stage

(maybe "view" will be enough, Clayton?)
Comment 4 Michal Fojtik 2016-02-04 03:41:57 EST
Also I don't think the fix that Clayton made for the registry to allow this is available in OSE yet. This flow currently works well in latest Origin.
Comment 5 Ricardo Alonso 2016-02-04 05:12:08 EST
Michal Fojtik:

Doing this could solve the problem, but looks like there is another issue. I built the dev app again to have new versions:

[root@master php-helloworld]# oc describe is php-helloworld -n dev
Name:			php-helloworld
Created:		38 hours ago
Labels:			app=php-helloworld
Annotations:		openshift.io/generated-by=OpenShiftNewApp
			openshift.io/image.dockerRepositoryCheck=2016-02-02T19:58:51Z
Docker Pull Spec:	172.30.103.87:5000/dev/php-helloworld

Tag	Spec		Created		PullSpec									Image
latest	<pushed>	4 minutes ago	172.30.103.87:5000/dev/php-helloworld@sha256:8e4c17cae33679f022ccbf2f2bfeab035dfb3f6b4ea70efdb927709ccdf58606	
			36 hours ago	172.30.103.87:5000/dev/php-helloworld@sha256:757a99c336638c2473bb2fe973c9daed428f0b96de8b77a3f1575d125b3a4085	
			38 hours ago	172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4	

Now I have 3 versions. On the first version I created the tag like you saidon the project prod:

[root@node ~]# oc tag dev/php-helloworld:latest prod/php-helloworld:latest
Tag php-helloworld:latest set to dev/php-helloworld@sha256:8e4c17cae33679f022ccbf2f2bfeab035dfb3f6b4ea70efdb927709ccdf58606.
[root@node ~]# oc describe is php-helloworld -n prod
Name:			php-helloworld
Created:		36 minutes ago
Labels:			app=php-helloworld
Annotations:		openshift.io/generated-by=OpenShiftNewApp
			openshift.io/image.dockerRepositoryCheck=2016-02-04T09:29:47Z
Docker Pull Spec:	172.30.103.87:5000/prod/php-helloworld

Tag	Spec												Created		PullSpec													Image
latest	dev/php-helloworld@sha256:8e4c17cae33679f022ccbf2f2bfeab035dfb3f6b4ea70efdb927709ccdf58606	35 minutes ago	172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4

But if you look the description of the is, it is pointing to the first version generated. I mean, the command "oc tag..." is not really updating the tag to the newest image. 

Maybe this is a different error from the first one?
Comment 6 Michal Fojtik 2016-02-04 08:14:55 EST
I think that is desired behavior of 'oc tag'. When you tag, the ImageStreamTag created in "prod" points to the exact SHA256 of the image you tagged.

In your case the tag points to "dev/php-helloworld:latest" which points to "8e4c17cae33679f022ccbf2f2bfeab035dfb3f6b4ea70efdb927709ccdf58606".
The "prod" ImageStreamTag "latest" also points to that exact SHA256. Maybe I'm missing something :)
Comment 7 Ricardo Alonso 2016-02-06 07:34:35 EST
Michal Fojtik:

If you pay attention on the information in my post, on the project dev I have an IS with three version (oldest to newest):

sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4
sha256:757a99c336638c2473bb2fe973c9daed428f0b96de8b77a3f1575d125b3a4085
sha256:8e4c17cae33679f022ccbf2f2bfeab035dfb3f6b4ea70efdb927709ccdf58606

On the project prod my is has just one tag: latest. 
The column "Spec" is correct pointing to the newest image on dev project, after running the "oc tag" command, but the file PullSpec is still pointing to the first version of the image.

172.30.103.87:5000/dev/php-helloworld@sha256:7944d9475125d1b85286ab4897def5e4a7ba433d5f74836157b42f23037ad4a4

So when you try to deploy the application on the prod project, it gets the first images, but the expected should be the last one (the one you tagged).
Comment 8 Clayton Coleman 2016-02-06 21:50:54 EST
This was fixed by https://github.com/openshift/origin/pull/6945 and was discussed for inclusion into 3.1.1.X as a hot fix.
Comment 9 Xingxing Xia 2016-02-14 22:46:46 EST
Verified against latest errata puddle, versions are:
openshift/oc v3.1.1.6-16-g5327e56
kubernetes v1.1.0-origin-1107-g4c8e6f4

From the comments above, the real issue of this bug is in fact shown in comment 5 and 7, while the issue in bug description is solved in comment 3.

Verification steps:
1. oc login and create projects xxia-dev
2. Create new app which creates a build:
$ oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git
3. Trigger a new build again:
$ oc start-build ruby-hello-world
4. After the above builds complete, check image stream:
$ oc describe is ruby-hello-world
Name:                   ruby-hello-world
<-- snip -->
Tag     Spec            Created                 PullSpec                                                                                Image
latest  <pushed>        28 minutes ago          <Integrated registry ip>:5000/xxia-dev/ruby-hello-world@sha256:6681c9e69976fad1ccd72e4ff753d6353fcd315564d6302eaab7106f93455bd7
                        About an hour ago       <Integrated registry ip>:5000/xxia-dev/ruby-hello-world@sha256:8993a063fee2513ef9dd17b7a7e520bf02ac0d7e633755de608337af8a165343

5. Create another project xxia-prod
1> $ oc new-project xxia-prod
2> Tag image from project xxia-dev to project xxia-prod
$ oc tag xxia-dev/ruby-hello-world:latest xxia-prod/prod:latest
3> Check which is pointed by the imageStreamTag xxia-prod/prod:latest
$ oc describe is prod -n xxia-prod
Name:                   prod
<-- snip -->
Tag     Spec                                                                                                    Created         PullSpec                                                                                                                Image
latest  xxia-dev/ruby-hello-world@sha256:6681c9e69976fad1ccd72e4ff753d6353fcd315564d6302eaab7106f93455bd7       16 seconds ago  <Integrated registry ip>:5000/xxia-dev/ruby-hello-world@sha256:6681c9e69976fad1ccd72e4ff753d6353fcd315564d6302eaab7106f93455bd7

In step 5.3, xxia-prod/prod:latest points to 6681c9e6..., the newest built image, this is the expected result.

The issue is fixed, so move to VERIFIED.
Comment 10 Xingxing Xia 2016-03-02 00:06:12 EST
> $ oc policy add-role-to-user edit system:serviceaccount:prod:default -n stage
> 
> (maybe "view" will be enough, Clayton?)
@ Michal Fojtik

During writing case for this bug, found "view" is not enough. (Not sure if it is bug?)
Here is the result of "view" (Same as before `oc policy` gives "view" permission):
$ oc describe pod/sample-app-1-zf8ab -n prod
...
Failed to pull image "172.30.225.201:5000/stage/sample-app...": unauthorized: authentication required
...
Comment 11 Michal Fojtik 2016-03-02 02:47:20 EST
Xingxing Xia: should be edit "edit", I confirmed this with Jordan. I think we are OK here :)

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