Bug 1311863

Summary: oc import-image fails if tag 1.0 or latest is not defined
Product: OpenShift Container Platform Reporter: Josef Karasek <jkarasek>
Component: ocAssignee: Fabiano Franz <ffranz>
Status: CLOSED NOTABUG QA Contact: Wei Sun <wsun>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: aos-bugs, jkarasek, jokerman, jvallejo, mmccomas
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-01 15:47:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Josef Karasek 2016-02-25 08:53:43 UTC
Description of problem:
When using an image which doesn't define tag 1.0 or latest, oc import-image throws following message:

error: unable to import image: [the default tag "1.0" has not been set on repository "jkarasek/archiva", the default tag "latest" has not been set on repository "jkarasek/archiva"]

Process also exits with other status than 0 
# echo $?
1

But the update operations succeeds - a tag is updated.


Version-Release number of selected component (if applicable):
# oc version
oc v3.1.1.6
kubernetes v1.1.0-origin-1107-g4c8e6f4

How reproducible:


Steps to Reproduce:
1.create image stream for image that doesn't define 1.0 or latest tag
2.oc import-image


Actual results:
Image stream update succeeds, but a false error message is thrown and process exits with exit code 1

Expected results:
Tags are updated. More meaningful message is present and process exits with status code 0.

Additional info:

Comment 1 Juan Vallejo 2017-10-20 22:14:25 UTC
Josef, is this issue still occurring? Could you try with a newer client and see if a better error message occurs?

If you don't have an imagestreamtag for the "latest" tag, you should specify <imagestreamname>:<custom_tag_name>

Comment 3 Josef Karasek 2017-11-01 11:28:18 UTC
Hey Juan, I had a look at it and to be honest I don't understand the way `oc import-image` is designed.

Most common workflow of publishing software as container images is to create a new image, give it a unique tag and push it to a remote registry (red hat, docker hub, etc.). This is for example what we do with our S2I images. If `oc import-image` ignores new tags in the remote registry, we're out of this workflow. Operators then have to track new tags in the remote registry manually, using `oc tag`, as you suggest.
Imagine an ops team that have 20 image streams and each of them gets an update once a week. That's unbearable manual burden on the ops team.

Do we have a way to automate this process or some idioms I'm not aware of?

Regarding the error msg - yes, it's more clear that tag 'latest' is expected to always exist, even though that doesn't have to be the case.
In my tests I pushed the 'latest' and one more tag named 'tag2' at the same time. Then ran `oc import-image` and tag 'latest' was found. Tag 'tag2' was ignored. But I would expect it to be also associated with the image stream.
I was able to do that manually using `oc tag`, but as I outlined before, that is horrible experience for the ops guys.

Comment 4 Josef Karasek 2017-11-01 11:44:34 UTC
Found the `--all=true` switch for `oc import-image`. That's the automation I was looking for. Thanks for looking in to this. Good to close the issue now.