oc import-image --insecure with specific tag creates istag that points to :latest #8440

sosiouxme · 2016-04-09T21:35:07Z

When I create an imagestream for an insecure registry and the oc import-image --insecure name:tag, it's imported, but the tag is pointing at the :latest tag instead of the one I wanted.

Version

oc v1.1.6-48-g561e4fa
kubernetes v1.2.0-36-g4a3f9c5

Steps To Reproduce

Create the following IS:

apiVersion: v1
kind: ImageStream
metadata:
  labels:
    component: support
    logging-infra: support
    provider: openshift
  name: logging-elasticsearch
spec:
  dockerImageRepository: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch

oc import-image --insecure logging-elasticsearch:3.1.0
oc describe istag logging-elasticsearch:3.1.0 | grep Image

Current Result

Docker Image:   brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:latest
Image Name:     f4c2de05eadfe6260c73d7dacbd731ddcbb1d74113036a1bd54e013075440c09
Image Created:  3 days ago

Expected Result

Docker Image:   brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:3.1.0

Additional Information

This is a test blocker for aggregated logging.

Tags created with --insecure --all look right. Just the specific import points to :latest.

$ oc get all -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: ImageStream
  metadata:
    annotations:
      openshift.io/image.dockerRepositoryCheck: 2016-04-09T21:26:51Z
    creationTimestamp: 2016-04-09T21:26:47Z
    generation: 2
    labels:
      component: support
      logging-infra: support
      provider: openshift
    name: logging-elasticsearch
    namespace: logging2
    resourceVersion: "2795"
    selfLink: /oapi/v1/namespaces/logging2/imagestreams/logging-elasticsearch
    uid: c3c5b7a0-fe99-11e5-b5a3-52540088403e
  spec:
    dockerImageRepository: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch
    tags:
    - annotations: null
      from:
        kind: DockerImage
        name: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch
      generation: 2
      importPolicy:
        insecure: true
      name: 3.1.0
  status:
    dockerImageRepository: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch
    tags:
    - items:
      - created: 2016-04-09T21:26:51Z
        dockerImageReference: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:latest
        generation: 2
        image: f4c2de05eadfe6260c73d7dacbd731ddcbb1d74113036a1bd54e013075440c09
      tag: 3.1.0
kind: List
metadata: {}

The text was updated successfully, but these errors were encountered:

soltysh · 2016-04-11T12:01:10Z

Your specific usecase works as follows. You've created an IS which points to brew-pulp-docker01....:8888/openshift3/logging-elasticsearch, since no tag is specified latest is always taken. We call this usecase where you specify entire repository you want to import.
Since this is insecure repo at the time you're invoking oc import-image there's no information about tags that exists in the repository. Thus we add latest to the general repo. If successful import would be executed beforehand, re-import of a specific tag just refreshes metadata about the tag (if there is new one available). It does make sense to use the tag a user supplied though, will work on a fix.

As a workaround, since you've mentioned this block you, I'd suggest importing image with oc import-image --insecure brew-pulp-docker01.....com:8888/openshift3/logging-elasticsearch:3.1.0 --confirm which will create new, preferred spec for your import, which puts every tag as a separate item:

apiVersion: v1
kind: ImageStream
metadata:
  name: logging-elasticsearch
spec:
  tags:
  - from:
      kind: DockerImage
      name: brew-pulp-docker01.....com:8888/openshift3/logging-elasticsearch:3.1.0
    importPolicy:
      insecure: true
    name: 3.1.0

or creating one as above manually, which should unblock you immediately.

@pweil- mind assigning

soltysh · 2016-04-11T12:10:59Z

There's also --from flag that you might use to address that use-case ;)

soltysh · 2016-04-11T12:17:51Z

It does make sense to use the tag a user supplied though, will work on a fix.

After looking more into the code, I'm changing my mind this is working as expected, see this line.

soltysh · 2016-04-11T13:10:26Z

@sosiouxme if you agree please close the issue.

sosiouxme · 2016-04-11T14:38:14Z

@soltysh I've been fiddling with this for a bit and I think it would help for me to provide more context for the use case. The use case (logging deployer) is that I don't actually know in advance whether the repository will be secure or not. It's created according to a template where the user supplies the registry. This is enterprise software, so I don't want to just allow non-secure repositories by default, but there's no way in the template to optionally add an importPolicy (for instance) based on the parameters, because you can only fill in values, not add elements. However we need to use the same deployer and template for both production and pre-production QE images. So if we follow the use case and start with a (default secured) IS then the only thing I could get working at all was the --from flag.

Now this might be working as designed, but I would not say it's working as expected. At least, not from the standpoint of a dumb user like myself. At the least, I would say it is inconsistent.

If you import with --all --insecure you get some correct tags (a subset of existing), but if you then import with the specific :tag you want, you get that tag pointing at :latest (and you need good eyes to notice).
If you add an insecure annotation to the IS (I could vary the value via the template) and import --insecure is:tag then it imports the tag as I expect. But if you first import without --insecure, realize your mistake and add --insecure the tag still ends up pointing at latest. And you can't even delete the tag properly then; the describe at first indicates two instances of the same tag, then if you delete one, one instance that can't be deleted. At least, deleting the tag doesn't allow proper importing afterward.
There is something about trying to import :3.1.0 specifically that seems to end up in many cases with :3.1 instead - side issue most likely, but it's really confusing.

So, we do have a workaround and this isn't completely blocked now, but it's awfully confusing and easy to shoot your own foot as implemented. Maybe we need a third party to give an opinion on this?

soltysh · 2016-04-11T15:10:53Z

@smarterclayton do we want to allow importing not imported tags through import-image? Currently we will notify the user no such tag exists and that he should create one with oc tag, which is ok for the repos where we've previously fetched the tags. But for the cases where previous import failed, or for the cases where we've limited the no of imported tags, @sosiouxme has a right we would want to be able to import new tags? wdyt?

chunyunchen · 2016-04-12T13:42:21Z

I tried two below workarounds, but still do not work as expected:

$ oc import-image logging-auth-proxy:3.2.0 --insecure=true --from brew-pulp-docker01...com:8888/openshift3/logging-auth-proxy:3.2.0

error: the tag "3.2.0" points to "brew-pulp-docker01...com:8888/openshift3/logging-auth-proxy" - use the 'tag' command if you want to change the source to "brew-pulp-docker01...com:8888/openshift3/logging-auth-proxy:3.2.0"

$ oc import-image brew-pulp-brew-pulp-docker01...com:8888/openshift3/logging-auth-proxy:3.2.0 --insecure=true --confirm

Note: still use :latest tag in pod
<------------sinp----------->
Containers:
kibana:
Container ID: docker://f13d86683047665c31409f99d1eb9e2a58e3f9ea18fae90419c27b1918fd715d
Image: brew-pulp-brew-pulp-docker01...com:8888/openshift3/logging-kibana:latest
Image ID: docker://3ce38d90561782969f98f387ba96b0e8411ee58a76878fcbd194ed64f54150a9
Port:
QoS Tier:
memory: BestEffort
cpu: BestEffort
State: Running
Started: Tue, 12 Apr 2016 21:37:42 +0800
Last State: Terminated
Reason: Error
Exit Code: 1
Started: Tue, 12 Apr 2016 21:37:25 +0800
Finished: Tue, 12 Apr 2016 21:37:34 +0800
Ready: True
Restart Count: 1
Environment Variables:
ES_HOST: logging-es
ES_PORT: 9200
kibana-proxy:
Container ID: docker://00c2c265bd954e33607300cd003aad53927ed99ed0af676098c04abcaa56a568
Image: brew-pulp-brew-pulp-docker01...com:8888/openshift3/logging-auth-proxy:latest
Image ID: docker://3d6792a3aeed859baa0b825db00fe3f2c20f7a4605ee00f3897acedf4f869a7e
<----------------snip--------------->

soltysh · 2016-04-12T14:05:40Z

$ oc import-image logging-auth-proxy:3.2.0 --insecure=true --from brew-pulp-docker01...com:8888/openshift3/logging-auth-proxy:3.2.0

This will not work, because you're trying to change the tag. That's why it's suggesting to use oc tag instead.

$ oc import-image brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-auth-proxy:3.2.0 --insecure=true --confirm

Works perfectly ok, just run:

$ oc import-image brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-auth-proxy:3.2.0 --insecure=true --confirm
The import completed successfully.

Name:           logging-auth-proxy
Created:        Less than a second ago
Labels:         <none>
Annotations:        openshift.io/image.dockerRepositoryCheck=2016-04-12T14:04:21Z
Docker Pull Spec:   172.30.74.214:5000/test/logging-auth-proxy

Tag Spec                                                Created         PullSpecImage
3.2.0   brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-auth-proxy:3.2.0 !  Less than a second ago  <same>  363e6ee61a085ff58a38247a7b8f4919c08af98bf1f1650f4f7f5f24a3f83fa9

  ! tag is insecure and can be imported over HTTP or self-signed HTTPS

@chunyunchen can you show me the output of the import command?

sosiouxme · 2016-04-12T14:32:32Z

$ oc create -f -
apiVersion: v1
kind: ImageStream
metadata:
  labels:
    component: support
    logging-infra: support
    provider: openshift
  name: logging-elasticsearch
spec:
  dockerImageRepository: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch


imagestream "logging-elasticsearch" created
$ oc import-image brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:3.2.0 --insecure=true --confirm
The import completed successfully.

Name:                   logging-elasticsearch
Created:                14 seconds ago
Labels:                 component=support
                        logging-infra=support
                        provider=openshift
Annotations:            openshift.io/image.dockerRepositoryCheck=2016-04-12T14:31:43Z
Docker Pull Spec:       brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch

Tag     Spec                                                                                    Created                 PullSpec                                           Image
3.2.0   brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch ! Less than a second ago  brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:latest        f4c2de05eadfe6260c73d7dacbd731ddcbb1d74113036a1bd54e013075440c09

  ! tag is insecure and can be imported over HTTP or self-signed HTTPS

Note the PullSpec ends up with :latest in it.

sosiouxme · 2016-04-12T14:42:25Z

Only thing that worked for me:

$ oc import-image logging-elasticsearch --from=brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:3.2.0 --insecure=true 
The import completed successfully.

Name:                   logging-elasticsearch
Created:                About a minute ago
Labels:                 component=support
                        logging-infra=support
                        provider=openshift
Annotations:            openshift.io/image.dockerRepositoryCheck=2016-04-12T14:35:29Z
Docker Pull Spec:       brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch

Tag     Spec                                                                                            Created                 PullSpec        Image
latest  brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:3.2.0 !   Less than a second ago  <same>          f4c2de05eadfe6260c73d7dacbd731ddcbb1d74113036a1bd54e013075440c09

  ! tag is insecure and can be imported over HTTP or self-signed HTTPS

Edit: I just noticed the istag is actually wrong on this - it's tagged as "latest" instead of 3.2.0 though that's what it points to. And you can't oc tag it to the right thing either. So this is back to blocking tests, the apparent workaround being to create the IS just right to begin with (not very compatible with the deployer).

soltysh · 2016-04-12T14:58:22Z

@sosiouxme here are the differences between different calls you're doing:

oc import-image logging-elasticsearch --from=brew..:8888/openshift3/logging-elasticsearch:3.2.0 --insecure=true

Is saying import logging-elasticsearch:3.2.0 into logging-elasticsearch, which means import into latest tag, because none was specified. You need to have the IS in place, otherwise it'll complain about it and suggests adding --confirm.

oc import-image brew...:8888/openshift3/logging-elasticsearch:3.2.0 --insecure=true --confirm

Assuming you don't have IS will create one with just single tag pointing to 3.2.0. Otherwise it'll match to existing IS and tags, if you have logging-elasticsearch IS with 3.2.0 tag it'll re-import the image, otherwise it'll complain about non-existing tag, suggesting to use oc tag.

Last call is the same as first, thus you're getting that result. I realize this might be confusing but I hope you get the general flow. If not I'd suggest we need to work on docs for import-image.

sosiouxme · 2016-04-12T15:32:01Z

You're right, this worked perfectly, thanks:

oc import-image logging-elasticsearch:3.2.0 --from=brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-elasticsearch:3.2.0 --insecure=true

I thought you were telling @chunyunchen that wouldn't work as it's trying to change the tag. Perhaps I misread.

The docs do need some work... Just hasn't been a priority for me yet (also my understanding is evidently not good enough).

chunyunchen · 2016-04-13T02:07:08Z

@sosiouxme @soltysh
I tried below two workarounds, both work well:

$ oc import-image logging-elasticsearch:3.2.0 --from=brew-pulp-docker01...com:8888/openshift3/logging-elasticsearch:3.2.0 --insecure=true
2.1 $ oc tag --source=docker brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-kibana:3.2.0 logging-kibana:3.2.0

2.2 $ oc import-image brew-pulp-docker01...com:8888/openshift3/logging-kibana:3.2.0 --insecure=true --confirm

the example results:
http://pastebin.test.redhat.com/365099

soltysh · 2016-04-13T08:03:27Z

@smarterclayton do we want to allow importing not imported tags through import-image? Or current oc tag suggestion we're giving is sufficient. This is for cases where initial import failed, and I know about the specific tag existing but since there's no one previously imported we'll fail and suggest oc tag instead.

smarterclayton · 2016-05-16T13:54:01Z

I'm debating whether we should move import-image to a new import image command and fix up the behaviors, then deprecate import-image.

aweiteka · 2016-05-16T14:20:20Z

@smarterclayton +1. Here are the primary use cases I think we need should consider:

I want to sync metadata referencing a remote registry image so I can use it as an imagestream.
I want to manually refresh the remote referenced image...
- to see if the latest tag is pointing to a different image.
- to debug a failed image sync (need --insecure flag or image requires auth)
I want to configure an automated "watch" or schedule a periodic sync of the remote image reference
- Question: if this operation isn't expensive could we just enable this by default? We imply this "added value" by calling it an image stream.
I want to import an image from a remote registry and download the blobs to the integrated registry so it's locally stored. See RFE https://trello.com/c/2mS800Cj

sosiouxme · 2016-05-18T13:05:45Z

I don't like having import-image as a top-level command either. Is there
anything else where the import verb will make sense? I was thinking just
load all the desired behaviors in oc tag or oc set or something.

On Mon, May 16, 2016 at 9:54 AM, Clayton Coleman notifications@github.com
wrote:

I'm debating whether we should move import-image to a new import image
command and fix up the behaviors, then deprecate import-image.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8440 (comment)

aweiteka · 2016-05-18T13:14:18Z

I don't like having import-image as a top-level command either. Is there anything else where the import verb will make sense? I was thinking just load all the desired behaviors in oc tag or oc set or something.

Yes, and my use case was drafted using language that makes sense to me. I'm not stuck on anything but those verbs are...

sync
refresh (or resync or update)
import

I also think we could put this all under "tag" but would need some args referencing these verbs. An interesting noun that is meaningful to me is "remote".

smarterclayton · 2016-05-18T13:33:01Z

The "import" command is a good one stop shop for "how do I make an external
artifact relevant on my cluster". In this case, the artifact is an image.

Let's keep iterating on the use cases and make sure we flush out any lack
of clarity.

On Wed, May 18, 2016 at 9:14 AM, Aaron Weitekamp notifications@github.com
wrote:

I don't like having import-image as a top-level command either. Is there
anything else where the import verb will make sense? I was thinking just
load all the desired behaviors in oc tag or oc set or something.

Yes, and my use case was drafted using language that makes sense to me.
I'm not stuck on anything but those verbs are...

sync

refresh (or resync or update)

import

I also think we could put this all under "tag" but would need some args
referencing these verbs. An interesting noun that is meaningful to me is
"remote".

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8440 (comment)

openshift-bot · 2018-02-18T10:59:37Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot · 2018-03-20T11:12:51Z

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

openshift-bot · 2018-04-19T11:16:46Z

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

sosiouxme mentioned this issue Apr 9, 2016

hardcode for image version for es,curator,kibana components openshift/origin-aggregated-logging#107

Closed

soltysh mentioned this issue Apr 11, 2016

oc import-image doesn't take insecure annotation into consideration when importing #8452

Closed

danmcp added component/imageregistry priority/P2 labels Apr 11, 2016

danmcp assigned soltysh Apr 11, 2016

soltysh assigned miminar and unassigned soltysh Aug 23, 2017

openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 18, 2018

openshift-ci-robot added the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Mar 20, 2018

openshift-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 20, 2018

openshift-ci-robot closed this as completed Apr 19, 2018

oc import-image --insecure with specific tag creates istag that points to :latest #8440

oc import-image --insecure with specific tag creates istag that points to :latest #8440

sosiouxme commented Apr 9, 2016

soltysh commented Apr 11, 2016

soltysh commented Apr 11, 2016

soltysh commented Apr 11, 2016

soltysh commented Apr 11, 2016

sosiouxme commented Apr 11, 2016

soltysh commented Apr 11, 2016

chunyunchen commented Apr 12, 2016

soltysh commented Apr 12, 2016

sosiouxme commented Apr 12, 2016

sosiouxme commented Apr 12, 2016

soltysh commented Apr 12, 2016

sosiouxme commented Apr 12, 2016

chunyunchen commented Apr 13, 2016

soltysh commented Apr 13, 2016

smarterclayton commented May 16, 2016

aweiteka commented May 16, 2016

sosiouxme commented May 18, 2016

aweiteka commented May 18, 2016

smarterclayton commented May 18, 2016

openshift-bot commented Feb 18, 2018

openshift-bot commented Mar 20, 2018

openshift-bot commented Apr 19, 2018

oc import-image --insecure with specific tag creates istag that points to :latest #8440

oc import-image --insecure with specific tag creates istag that points to :latest #8440

Comments

sosiouxme commented Apr 9, 2016

Version

Steps To Reproduce

Current Result

Expected Result

Additional Information

soltysh commented Apr 11, 2016

soltysh commented Apr 11, 2016

soltysh commented Apr 11, 2016

soltysh commented Apr 11, 2016

sosiouxme commented Apr 11, 2016

soltysh commented Apr 11, 2016

chunyunchen commented Apr 12, 2016

soltysh commented Apr 12, 2016

sosiouxme commented Apr 12, 2016

sosiouxme commented Apr 12, 2016

soltysh commented Apr 12, 2016

sosiouxme commented Apr 12, 2016

chunyunchen commented Apr 13, 2016

soltysh commented Apr 13, 2016

smarterclayton commented May 16, 2016

aweiteka commented May 16, 2016

sosiouxme commented May 18, 2016

aweiteka commented May 18, 2016

smarterclayton commented May 18, 2016

openshift-bot commented Feb 18, 2018

openshift-bot commented Mar 20, 2018

openshift-bot commented Apr 19, 2018