BUG REPORT INFORMATION
Output of docker version:
Client:
Version: 1.10.2
API version: 1.22
Go version: go1.5.3
Git commit: c3959b1
Built: Mon Feb 22 22:37:33 2016
OS/Arch: linux/amd64
Server:
Version: 1.10.2
API version: 1.22
Go version: go1.5.3
Git commit: c3959b1
Built: Mon Feb 22 22:37:33 2016
OS/Arch: linux/amd64
Output of docker info:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 6
Server Version: 1.10.2
Storage Driver: vfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 3.13.0-74-generic
Operating System: Alpine Linux v3.3 (containerized)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.704 GiB
Name: 97b6482c3a10
ID: XUPJ:VGFT:2B7I:HOQU:BJQ7:3L4S:SGTL:ZAOO:Q57R:WXHL:BFKY:UWQ2
WARNING: No swap limit support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
- Create an image or use an existing one.
- Obtain the image's Digest ID:
docker inspect --format='{{ .Id }}' -- rjmtest
sha256:97ed62d4dc30d1f53b903dac1e90c8fee4a77a30f0099b42f34f67cb5b17018c
- Attempt to create a container using either docker run/create but remove the
sha256: prefix:
docker run 97ed62d4dc30d1f53b903dac1e90c8fee4a77a30f0099b42f34f67cb5b17018c
docker: Invalid repository name (97ed62d4dc30d1f53b903dac1e90c8fee4a77a30f0099b42f34f67cb5b17018c), cannot specify 64-byte hexadecimal strings.
- Now remove the container using
docker rmi and the same 64-byte hexadecimal part of the Digest ID that failed when attempting to run/create:
docker rmi 97ed62d4dc30d1f53b903dac1e90c8fee4a77a30f0099b42f34f67cb5b17018c
Untagged: rjmtest:latest
Deleted: sha256:97ed62d4dc30d1f53b903dac1e90c8fee4a77a30f0099b42f34f67cb5b17018c
Deleted: sha256:884218f6feb1cee2f842cdbbed25bebfbe13d055fbd3254b1be6241f19eb90fb
Also, docker inspect accepts the same 64-byte hexadecimal part of the Digest ID that failed when attempting to run/create.
Describe the results you received:
In some cases, the specified Docker operation can use the 64-byte hexadecimal part of the Digest ID to identify an image and successfully complete. In other cases, the sha256: prefix must exist in order for the command to accept the complete ID.
Describe the results you expected:
- Given
docker run/create accept Digest IDs without a prefix but less than 64-bytes.
- Given commands such as ``docker rmi/inspect` accept the 64-byte hexadecimal part of the Digest ID without the prefix.
It seems to me that run/create and any other image command should accept an image Digest ID without its prefix. However, this ambiguity needs to be resolved by Docker.
Provide additional info you think is important:
Although I appreciate the content based IDs, I don't understand why this low level implementation concern has become 'visible'. From the perspective of a Developer using Docker, I just want a UUID whose scope/boundary of uniqueness is well understood. I would recommend removing the sha256: prefix so the concept of content addressability and how it's implemented stays hidden (encapsulated) within the lower, more implementation specific layers of Docker Engine. Right now, this notion leaks/bubbles to the surface.
BUG REPORT INFORMATION
Output of
docker version:Output of
docker info:Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
sha256:prefix:docker rmiand the same 64-byte hexadecimal part of the Digest ID that failed when attempting to run/create:Also,
docker inspectaccepts the same 64-byte hexadecimal part of the Digest ID that failed when attempting to run/create.Describe the results you received:
In some cases, the specified Docker operation can use the 64-byte hexadecimal part of the Digest ID to identify an image and successfully complete. In other cases, the
sha256:prefix must exist in order for the command to accept the complete ID.Describe the results you expected:
docker run/createaccept Digest IDs without a prefix but less than 64-bytes.It seems to me that run/create and any other image command should accept an image Digest ID without its prefix. However, this ambiguity needs to be resolved by Docker.
Provide additional info you think is important:
Although I appreciate the content based IDs, I don't understand why this low level implementation concern has become 'visible'. From the perspective of a Developer using Docker, I just want a UUID whose scope/boundary of uniqueness is well understood. I would recommend removing the
sha256:prefix so the concept of content addressability and how it's implemented stays hidden (encapsulated) within the lower, more implementation specific layers of Docker Engine. Right now, this notion leaks/bubbles to the surface.