Bug 1311863 - oc import-image fails if tag 1.0 or latest is not defined
oc import-image fails if tag 1.0 or latest is not defined
Status: CLOSED NOTABUG
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
3.1.0
All All
unspecified Severity low
: ---
: ---
Assigned To: Fabiano Franz
Wei Sun
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-25 03:53 EST by Josef Karasek
Modified: 2017-11-01 11:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-11-01 11:47:31 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 Josef Karasek 2016-02-25 03:53:43 EST
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 18:14:25 EDT
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 07:28:18 EDT
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 07:44:34 EDT
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.