Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1442855 - layers have zero size in imagestreams [NEEDINFO]
layers have zero size in imagestreams
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry (Show other bugs)
3.4.1
Unspecified Unspecified
urgent Severity urgent
: ---
: 3.4.z
Assigned To: Oleg Bulatov
ge liu
:
Depends On:
Blocks: 1447967 1457042 1457043
  Show dependency treegraph
 
Reported: 2017-04-17 15:02 EDT by Luiz Carvalho
Modified: 2017-10-25 09:00 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: the size of a cached layer doesn't counted Consequence: the layer size for cached layers is zero Fix: count the size for cached layers Result: images have proper layer sizes
Story Points: ---
Clone Of:
: 1447967 1457042 1457043 (view as bug list)
Environment:
Last Closed: 2017-10-25 09:00:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
obulatov: needinfo? (jkaur)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:3049 normal SHIPPED_LIVE OpenShift Container Platform 3.6, 3.5, and 3.4 bug fix and enhancement update 2017-10-25 11:57:15 EDT

  None (edit)
Description Luiz Carvalho 2017-04-17 15:02:54 EDT
Description of problem:
After creating an ImageStream object that references an image in registry.access.redhat.com layers are not pulled.


Version-Release number of selected component (if applicable):
v3.4.1.12

How reproducible:
Always

Steps to Reproduce:
1. oc cluster up --version v3.4 --image registry.access.redhat.com/openshift3/ose
2. oc create -f - << EOF
{
    "kind": "ImageStream",
    "apiVersion": "v1",
    "metadata": {
        "name": "rhel7-test"
    },
    "spec": {
        "dockerImageRepository": "registry.access.redhat.com/rhel7"
    }
}
EOF
3. Wait until tags are populated for imagestream rhel7-test
4. Check size of layers: oc get imagestreamtag lucarval-rhel7-test:latest -o json

Actual results:
.image.dockerImageLayers reports empty layers:
[
  {
    "name": "sha256:e50b1d9e90ba6803b2c3b8712a71299dafd614d8f8f6616bb692e2873207188f",
    "size": 0,
    "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-gtar"
  },
  {
    "name": "sha256:93b630859c0ea7dbe2b30ed22ccc5c53be542619405c6c4cb83cd2b5e7419648",
    "size": 0,
    "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-gtar"
  }
]


Expected results:
Expect correct size to be set. 

Additional info:
Using a different container registry to pull image from does not exhibit this issue. Tried "docker.io/centos" and "brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/rhel7" (insecure registry), both seem to work properly.

Issue is not seen when using an older version of OpenShift: "--version v3.4"
Comment 1 Luiz Carvalho 2017-04-17 15:09:29 EDT
Typo in previous comment... It should read:

Issue is not seen when using an older version of OpenShift: "--version v3.3"
Comment 3 rcerven 2017-04-25 10:36:04 EDT
I can actually see the problem with version 3.3 as well

but only for last tag (latest is fine)

rhel7-test:7.3 (same image as in latest) shows 0 size
rhel7-test:7.2 is OK
rhel7-test:7.0-21 is OK
rhel7-test:7.0-23 is OK
rhel7-test:latest is OK
Comment 5 Michal Minar 2017-05-04 05:12:49 EDT
Manifest must contain correct layer sizes - at least manifest V2 schema 2. It's not OpenShift's fault that registry.access.redhat.com serves bad data.

This should be fixed on pulp's side or in our in build's infrastructure.

I wonder why the docker client doesn't fail in pulling such an image. I guess it's satisfied with just matching digests.

In OpenShift, we have a code that verifies/updates blob sizes if 0. Changing the code to handle 0 sizes for schema 2 would be trivial I guess. Nevertheless, I would consider it an low-priority bug for OpenShift if bug at all.
Comment 6 Luiz Carvalho 2017-05-04 08:27:24 EDT
Keep in mind that size of 0 is merely a symptom. The real problem is that the image is actually not pulled from external registry into OpenShift's registry properly. 

Attempting to pull the image from OpenShift's internal registry causes an error:

$ docker pull 172.30.1.1:5000/myproject/rhel7-test:latest
Trying to pull repository 172.30.1.1:5000/myproject/rhel7-test ... 
manifest unknown: manifest unknown


Further inspection shows that tags have been populated as expected, but something is up with the manifests:

$ curl -H "Authorization: Bearer $(oc whoami -t)" -L http://172.30.1.1:5000/v2/myproject/rhel7-test/tags/list
{"name":"myproject/rhel7-test","tags":["7.2","7.0-21","7.0-23","latest","7.3"]}

$ curl -H "Authorization: Bearer $(oc whoami -t)" -L http://172.30.1.1:5000/v2/myproject/rhel7-test/manifests/latest
{"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":{"Op":"Get","URL":"https://registry.access.redhat.com/v2/","Err":{"Op":"dial","Net":"tcp","Source":null,"Addr":null,"Err":{"Err":"read udp 172.17.0.4:59706-\u003e10.18.33.22:53: read: no route to host","Name":"registry.access.redhat.com","Server":"10.18.33.22:53","IsTimeout":false,"IsTemporary":false}}}}]}
Comment 9 Michal Minar 2017-05-11 09:50:31 EDT
This [1] and/or [2] should help.

- https://docs.openshift.com/container-platform/3.4/install_config/http_proxies.html#proxying-docker-pull
- https://docs.openshift.com/container-platform/3.4/install_config/http_proxies.html#configuring-hosts-for-proxies

The proxy config option you mention is indeed something else which shouldn't be touched.
Comment 11 Oleg Bulatov 2017-05-12 09:40:34 EDT
https://github.com/openshift/origin/pull/14166
Comment 12 openshift-github-bot 2017-05-25 08:35:44 EDT
Commit pushed to master at https://github.com/openshift/origin

https://github.com/openshift/origin/commit/5e2c3f3073501b2de7a192a3496f6ad7b9c24de7
Set layer size whether it found in cache or not

Fixes bug 1442855

Signed-off-by: Oleg Bulatov <obulatov@redhat.com>
Comment 13 ge liu 2017-05-25 22:21:26 EDT
The code merged in Image: devenv-rhel7_6269 about 15 hours ago, and still could not find the image in aws:AMI.
Comment 14 Wang Haoran 2017-05-30 22:36:23 EDT
Change to post status as no new puddles built out now
Comment 15 Wang Haoran 2017-05-30 22:43:39 EDT
Let's use this track version 3.4.1 
PR not merged: https://github.com/openshift/ose/pull/762
Comment 16 ge liu 2017-06-13 23:26:00 EDT
There is not new 3.4 puddle ready for verify this bug, we will verify it after new puddle ready.
Comment 17 ge liu 2017-06-14 23:08:36 EDT
Verified in OCP
# openshift version
openshift v3.4.1.37
kubernetes v1.4.0+776c994
etcd 3.1.0-rc.0

1.# oc create -f /tmp/lg.yaml
imagestream "rhel7-test" created

2.# oc get is
NAME         DOCKER REPO                        TAGS                         UPDATED
rhel7-test   registry.access.redhat.com/rhel7   latest,7.3,7.2 + 2 more...   5 seconds ago

# oc get istag rhel7-test:latest -o json
{
    "kind": "ImageStreamTag",
    "apiVersion": "v1",
................................

"dockerImageLayers": [
            {
                "name": "sha256:4e5a7647df476dcb309aa02f6901239300e7103a914fd92acf540372c1dafe0c",
                "size": 72175335,
                "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-gtar"
            },
            {
                "name": "sha256:0001a3087112018853b83f67ffc311dab755d14393a69852d5e2f4aa01b35361",
                "size": 1194,
                "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-gtar"
            }
        ],
......................
Comment 28 errata-xmlrpc 2017-10-25 09:00:48 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:3049

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