Bug 1126775 - `docker load` clears `DockerVersion` and prevents push the tagged image to internal registry
Summary: `docker load` clears `DockerVersion` and prevents push the tagged image to in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Václav Pavlín
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
: 1126778 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-05 09:01 UTC by Guohua Ouyang
Modified: 2019-03-06 02:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-07 21:35:23 UTC


Attachments (Terms of Use)

Description Guohua Ouyang 2014-08-05 09:01:08 UTC
Description of problem:
`docker load` clears `DockerVersion`, which prevent to push the tagged image to internal registry.

#docker load -i rhel-server-docker-7.0-22.1.x86_64.tar.gz

# docker inspect redhat-rhel-server-7.0-x86_64 | tail
        "WorkingDir": ""
    },
    "Created": "2014-07-17T17:25:57.019509969Z",
    "DockerVersion": "",
    "Id": "26ac5f9b5cf6d6948f31691f06416381ac70317f3ca45ee7c0b44d91df88e760",
    "Os": "linux",
    "Parent": "",
    "Size": 147240395
}

# docker tag redhat-rhel-server-7.0-x86_64 10.66.111.144:5000/rhel

# docker push 10.66.111.144:5000/rhel
The push refers to a repository [10.66.111.144:5000/rhel] (len: 1)
Sending image list
Pushing repository 10.66.111.144:5000/rhel (1 tags)
26ac5f9b5cf6: Pushing 
2014/08/05 16:57:56 HTTP code 400 while uploading metadata: {"error": "Missing key `id' in JSON"}


upstream bug: https://github.com/docker/docker/issues/6340

Version-Release number of selected component (if applicable):
docker-1.1.2-6.el7.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Guohua Ouyang 2014-08-08 08:37:25 UTC
*** Bug 1126778 has been marked as a duplicate of this bug. ***

Comment 3 Daniel Walsh 2014-08-08 12:44:28 UTC
Docker registry rejects any docker image that has a version less then 0.10.0.  Which is causing this problem.

BTW Why are we marking these as private.  I would like to open a discussion with Docker about this bug.  Not sure if there is a good way to fix this other then allowing the user to specify the version of the image.

Comment 4 Guohua Ouyang 2014-08-08 22:52:00 UTC
(In reply to Daniel Walsh from comment #3)
> Docker registry rejects any docker image that has a version less then
> 0.10.0.  Which is causing this problem.
> 
> BTW Why are we marking these as private.  I would like to open a discussion
> with Docker about this bug.  Not sure if there is a good way to fix this
> other then allowing the user to specify the version of the image.

I marked this as private because there are private IP addresses mentioned in the bug description.

Comment 5 Daniel Walsh 2014-08-12 13:46:33 UTC
I am not sure what the fix is for this.  Since the tar ball has no json files to identify the docker version used to create the tar ball.  Allowing the user to specify the docker version seems like it is easily spoofed or mistake prone.  Adding the docker version of the tool that does the load is also wrong.

Comment 6 Guohua Ouyang 2014-08-13 08:16:55 UTC
(In reply to Daniel Walsh from comment #5)
> I am not sure what the fix is for this.  Since the tar ball has no json
> files to identify the docker version used to create the tar ball.  Allowing
> the user to specify the docker version seems like it is easily spoofed or
> mistake prone.  Adding the docker version of the tool that does the load is
> also wrong.

There is an json file in the tar ball, and there has the key “DockerVersion".

# cat 26ac5f9b5cf6d6948f31691f06416381ac70317f3ca45ee7c0b44d91df88e760/json 
{"Architecture":"amd64","Author":"","Comment":"Imported from -","Config":null,"Container":"","ContainerConfig":{"AttachStderr":false,"AttachStdin":false,"AttachStdout":false,"Cmd":null,"CpuShares":0,"Cpuset":"","Domainname":"","Entrypoint":null,"Env":null,"ExposedPorts":null,"Hostname":"","Image":"","Memory":0,"MemorySwap":0,"NetworkDisabled":false,"OnBuild":null,"OpenStdin":false,"PortSpecs":null,"StdinOnce":false,"Tty":false,"User":"","Volumes":null,"WorkingDir":""},"Created":"2014-07-17T17:25:57.019509969Z","DockerVersion":"1.0.0","Id":"26ac5f9b5cf6d6948f31691f06416381ac70317f3ca45ee7c0b44d91df88e760","Os":"linux","Parent":"","Size":139874178}

Comment 7 Daniel Walsh 2014-08-13 12:31:50 UTC
Ok, then it is a bug.  Sorry I just thought this was a flat tar of a directory.

Comment 8 Daniel Walsh 2014-08-13 12:40:08 UTC
Ouyang, I am thinking that the problem is in the creation of  rhel-server-docker-7.0-22.1.x86_64.tar.gz.  We need to create a new one of these using the latest docker.

Comment 9 Guohua Ouyang 2014-08-13 23:46:03 UTC
(In reply to Daniel Walsh from comment #8)
> Ouyang, I am thinking that the problem is in the creation of 
> rhel-server-docker-7.0-22.1.x86_64.tar.gz.  We need to create a new one of
> these using the latest docker.

agree on this.
I tested that saving a tar ball from the latest base rhel image, and loaded it on a clean environment, `DockerVersion` is there and could be pushed to internal registry.

Comment 10 William Henry 2014-08-22 18:16:08 UTC
So is this still a bug in docker load or is this something else? 

(From Dan's latest comment it looks like he changed his mind and thinks its,a bug in the creation of the tar. (?))

Comment 11 Daniel Walsh 2014-08-22 19:14:43 UTC
Yes this is a problem with the image and the docer version used to create it.  We need to make sure we have a clean image(s) with the correct data set.

Lets reassign this to Vacek.

Comment 12 Daniel Walsh 2014-09-12 19:16:10 UTC
Fixed in docker-1.2


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