Cleanup items from ImageRepository -> ImageStream change

[ncdc]

• consistent tag ordering (if not already there)
• make sure you can't set both spec.tags.dockerImageReference and spec.tags.from (Improve ImageStream validation to handle duplicate from and image reference #1628)
• ...

[jwforres]

When there is no spec for the image stream it seems to be both adding the images to the list of images for the "latest" tag, and creating unique tags for the image. See origin-ruby-sample in the gist.

https://gist.github.com/jwforres/a28ac9893894465f4247

Can be recreated by creating from examples/sample-app/application-template-stibuild.json and running a few builds

[ncdc]

This shouldn't be related to spec or no spec.

We technically are creating 2 tags with the v1 registry, but if we don't want to see them, I can remove the by-id tag from status.tags. Note, this won't be an issue with the v2 registry.

Sent from my iPhone

On Apr 7, 2015, at 2:09 PM, Jessica Forrester [email protected] wrote:

When there is no spec for the image stream it seems to be both adding the images to the list of images for the "latest" tag, and creating unique tags for the image. See origin-ruby-sample in the gist.

https://gist.github.com/jwforres/a28ac9893894465f4247

Can be recreated by creating from examples/sample-app/application-template-stibuild.json and running a few builds

—
Reply to this email directly or view it on GitHub.

[jwforres]

If this is temporary until we have v2 registry then I'm ok either way.

On 04/07/2015 02:19 PM, Andy Goldstein wrote:

This shouldn't be related to spec or no spec.

We technically are creating 2 tags with the v1 registry, but if we
don't want to see them, I can remove the by-id tag from status.tags.
Note, this won't be an issue with the v2 registry.

Sent from my iPhone

On Apr 7, 2015, at 2:09 PM, Jessica Forrester
[email protected] wrote:

When there is no spec for the image stream it seems to be both
adding the images to the list of images for the "latest" tag, and
creating unique tags for the image. See origin-ruby-sample in the gist.

https://gist.github.com/jwforres/a28ac9893894465f4247

Can be recreated by creating from
examples/sample-app/application-template-stibuild.json and running a
few builds

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#1577 (comment).

[jwforres]

When I have an ImageStream like the one below it creates the image record under the tag but the "image" field is set to empty string, is that expected?

ImageStream in the template:

{
      "apiVersion": "v1beta1",
      "kind": "ImageStream",
      "metadata": {
        "name": "dockerImgRef-ruby-20-centos7"
      },
      "spec": {
        "tags" : [
          {
            "name": "docker-test",
            "dockerImageReference" : "openshift/ruby-20-centos7:latest"
          }
        ]
      }
    }

ImageStream returned from api:

    {
      "metadata": {
        "name": "dockerImgRef-ruby-20-centos7",
        "namespace": "test",
        "selfLink": "/osapi/v1beta1/imageStreams/dockerImgRef-ruby-20-centos7?namespace=test",
        "uid": "a90d59d9-dd52-11e4-8d5d-54ee75107c12",
        "resourceVersion": "7798",
        "creationTimestamp": "2015-04-07T18:19:42Z"
      },
      "spec": {
        "tags": [
          {
            "name": "docker-test",
            "dockerImageReference": "openshift/ruby-20-centos7:latest"
          }
        ]
      },
      "status": {
        "dockerImageRepository": "172.30.17.38:5000/test/dockerImgRef-ruby-20-centos7",
        "tags": [
          {
            "tag": "docker-test",
            "items": [
              {
                "created": "2015-04-07T18:19:42Z",
                "dockerImageReference": "openshift/ruby-20-centos7:latest",
                "image": ""
              }
            ]
          }
        ]
      }
    }

[ncdc]

Yes, that is expected. With spec.tags, you will only ever see image populated when using from with kind=ImageStreamTag or kind=ImageStreamImage. And even then, it's possible to have a blank image. The rationale behind this is that if you set a spec tag to a dockerImageReference, it's an opaque string to us at that point, and we don't inspect it to try to determine the image id. Maybe if the dockerImageReference points to an image by id (foo/bar@sha256:abcd....) we could set the image field, but otherwise we aren't querying the remote registry on the fly to figure out the image id from the tag.

[jwforres]

In that case if I want to get more info on the image (like if i wanted to look at the ENV), is it imageStreamImage@ or can I not get more details?

[jwforres]

Sorry meant to say imageStreamImage/@

[ncdc]

Only if it comes from an image stream and we know about it. If stream A points at opaque dockerImageReference foo/bar@sha256:..., there's no guarantee that we have any record of that image in OpenShift.

Sent from my iPhone

On Apr 7, 2015, at 2:51 PM, Jessica Forrester [email protected] wrote:

Sorry meant to say imageStreamImage/@

—
Reply to this email directly or view it on GitHub.

[danmcp]

@ncdc What's left here?

[ncdc]

@danmcp I believe we can close this