Bug 1311863 - oc import-image fails if tag 1.0 or latest is not defined
Summary: oc import-image fails if tag 1.0 or latest is not defined
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.1.0
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
: ---
Assignee: Fabiano Franz
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-25 08:53 UTC by Josef Karasek
Modified: 2017-11-01 15:47 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-01 15:47:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


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