Red Hat Bugzilla – Bug 1311863
oc import-image fails if tag 1.0 or latest is not defined
Last modified: 2017-11-01 11:47:31 EDT
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:
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>
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.
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.