Bug 1437447
| Summary: | atomic pull image confuses users | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Alex Jia <ajia> |
| Component: | atomic | Assignee: | Brent Baude <bbaude> |
| Status: | CLOSED ERRATA | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.3 | CC: | amurdaca, bbaude, dwalsh, miabbott, myllynen |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-05-26 14:29:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
It looks like when 'skopeo' is copying the image into the docker storage, it does not use a fully qualified image name (as specified by the original 'atomic pull' command). I assume that the docker daemon just appends 'docker.io' by default? If I run the raw 'skopeo' command outside of 'atomic', I can see similar behavior: # /usr/bin/skopeo --policy=/etc/containers/policy.json --debug copy --remove-signatures docker://registry.access.redhat.com/rhel7:latest docker-daemon:rhel7:latest DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration DEBU[0000] Using "default-docker" configuration DEBU[0000] No signature storage configuration found for registry.access.redhat.com/rhel7:latest DEBU[0000] IsRunningImageAllowed for image docker:registry.access.redhat.com/rhel7:latest DEBU[0000] Using default policy section DEBU[0000] Requirement 0: allowed DEBU[0000] Overall: allowed DEBU[0000] GET https://registry.access.redhat.com/v2/ DEBU[0000] Ping https://registry.access.redhat.com/v2/ err <nil> DEBU[0000] Ping https://registry.access.redhat.com/v2/ status 200 DEBU[0000] GET https://registry.access.redhat.com/v2/rhel7/manifests/latest DEBU[0000] Will convert manifest from MIME type text/plain to application/vnd.docker.distribution.manifest.v2+json Copying blob sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 DEBU[0000] Downloading rhel7/blobs/sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 DEBU[0000] GET https://registry.access.redhat.com/v2/rhel7/blobs/sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 DEBU[0001] Detected compression format gzip 0 B / ? [--------------------------------------------------------------------=]DEBU[0001] Using original blob without modification DEBU[0001] docker-daemon: input with unknown size, streaming to disk first… 68.12 MB / ? [---------------------------------------------------------------=]DEBU[0019] … streaming done DEBU[0019] Sending as tar file sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 68.80 MB / ? [-------------------------------------=-------------------------] DEBU[0020] Consuming rest of the original blob to satisfy getOriginalLayerCopyWriter DEBU[0020] Computed DiffID sha256:827264d42df669fe0678762609a13603e92f33ba30a983a16c4e861a1d0c8d9f for layer sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 Copying blob sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0020] Downloading rhel7/blobs/sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0020] GET https://registry.access.redhat.com/v2/rhel7/blobs/sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0021] Detected compression format gzip 0 B / ? [--------------------------------------------------------------------=]DEBU[0021] Using original blob without modification DEBU[0021] docker-daemon: input with unknown size, streaming to disk first… DEBU[0021] … streaming done DEBU[0021] Sending as tar file sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0021] Consuming rest of the original blob to satisfy getOriginalLayerCopyWriter DEBU[0021] Computed DiffID sha256:9ca8c628d8e7fe2a156a3d0ded13a524998f81e531f3e0b3ca90ff6aa3d4cae5 for layer sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 Copying config sha256:41a4953dbf957cfc562935239a3153a5da6101f32fa30da7b4a506f23cfcde9d DEBU[0021] No compression detected 0 B / 4.49 KB [---------------------------------------------------------------]DEBU[0021] Using original blob without modification DEBU[0021] Sending as tar file sha256:41a4953dbf957cfc562935239a3153a5da6101f32fa30da7b4a506f23cfcde9d Writing manifest to image destination DEBU[0021] Sending as tar file manifest.json Storing signatures DEBU[0021] docker-daemon: Closing tar stream DEBU[0021] docker-daemon: Waiting for status 4.49 KB / 4.49 KB [===========================================================]DEBU[0029] docker-daemon: sending done, status <nil> # atomic images list REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE TYPE docker.io/rhel7 latest 41a4953dbf95 2017-02-22 17:30 192.54 MB docker # docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/rhel7 latest 41a4953dbf95 5 weeks ago 192.5 MB Strangely, if I modify the 'skopeo' command to copy the image into the docker storage with a fully qualified image name, the new image is not reflected in the output of 'atomic images list', but is updated in 'docker images' # /usr/bin/skopeo --policy=/etc/containers/policy.json --debug copy --remove-signatures docker://registry.access.redhat.com/rhel7:latest docker-daemon:registry.access.redhat.com/rhel7:latest DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration DEBU[0000] Using "default-docker" configuration DEBU[0000] No signature storage configuration found for registry.access.redhat.com/rhel7:latest DEBU[0000] IsRunningImageAllowed for image docker:registry.access.redhat.com/rhel7:latest DEBU[0000] Using default policy section DEBU[0000] Requirement 0: allowed DEBU[0000] Overall: allowed DEBU[0000] GET https://registry.access.redhat.com/v2/ DEBU[0000] Ping https://registry.access.redhat.com/v2/ err <nil> DEBU[0000] Ping https://registry.access.redhat.com/v2/ status 200 DEBU[0000] GET https://registry.access.redhat.com/v2/rhel7/manifests/latest DEBU[0000] Will convert manifest from MIME type text/plain to application/vnd.docker.distribution.manifest.v2+json Copying blob sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 DEBU[0000] Downloading rhel7/blobs/sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 DEBU[0000] GET https://registry.access.redhat.com/v2/rhel7/blobs/sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 DEBU[0001] Detected compression format gzip 0 B / ? [--------------------------------------------------------------------=]DEBU[0001] Using original blob without modification DEBU[0001] docker-daemon: input with unknown size, streaming to disk first… 68.56 MB / ? [---------------------------------------------------------------=]DEBU[0014] … streaming done DEBU[0014] Sending as tar file sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 68.80 MB / ? [-------------------------------------=-------------------------] DEBU[0014] Consuming rest of the original blob to satisfy getOriginalLayerCopyWriter DEBU[0014] Computed DiffID sha256:827264d42df669fe0678762609a13603e92f33ba30a983a16c4e861a1d0c8d9f for layer sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 Copying blob sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0014] Downloading rhel7/blobs/sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0014] GET https://registry.access.redhat.com/v2/rhel7/blobs/sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0015] Detected compression format gzip 0 B / ? [--------------------------------------------------------------------=]DEBU[0015] Using original blob without modification DEBU[0015] docker-daemon: input with unknown size, streaming to disk first… DEBU[0015] … streaming done DEBU[0015] Sending as tar file sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 DEBU[0015] Consuming rest of the original blob to satisfy getOriginalLayerCopyWriter DEBU[0015] Computed DiffID sha256:9ca8c628d8e7fe2a156a3d0ded13a524998f81e531f3e0b3ca90ff6aa3d4cae5 for layer sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 Copying config sha256:41a4953dbf957cfc562935239a3153a5da6101f32fa30da7b4a506f23cfcde9d DEBU[0015] No compression detected 0 B / 4.49 KB [---------------------------------------------------------------]DEBU[0015] Using original blob without modification DEBU[0015] Sending as tar file sha256:41a4953dbf957cfc562935239a3153a5da6101f32fa30da7b4a506f23cfcde9d Writing manifest to image destination DEBU[0015] Sending as tar file manifest.json Storing signatures DEBU[0015] docker-daemon: Closing tar stream DEBU[0015] docker-daemon: Waiting for status DEBU[0015] docker-daemon: sending done, status <nil> # atomic images list REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE TYPE docker.io/rhel7 latest 41a4953dbf95 2017-02-22 17:30 192.54 MB docker # docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/rhel7 latest 41a4953dbf95 5 weeks ago 192.5 MB registry.access.redhat.com/rhel7 latest 41a4953dbf95 5 weeks ago 192.5 MB Reading through the output it's a bit difficult - though - Micah, are you saying that using the FQ image name in skopeo (from atomic) is fixing this issue? I mean, what if you patch atomic to use the fully qualified image name and repeat all the steps? Does it work correctly? (In reply to Antonio Murdaca from comment #5) > I mean, what if you patch atomic to use the fully qualified image name and > repeat all the steps? Does it work correctly? I think this is the correct approach here. This gets into the discussion of 'what the user wants' and 'what we should do that is best for the user'. And in this case, I think we want to do do what is best for the user. The original problem reported that 'atomic pull rhel7' on a RHEL host ends up with a 'skopeo' command that looks like: /usr/bin/skopeo --policy=/etc/containers/policy.json --debug copy --remove-signatures docker://registry.access.redhat.com/rhel7:latest docker-daemon:rhel7:latest 'atomic' has provided the fully-qualified image name for the source image, but the destination image is not fully-qualified. To match user expectations, I think 'atomic' should be changed so that the fully-qualified version of the image is used for the source and destination images. Right, in this case, the source image name is the "source" of the truth since it gets fully qualified and we should use that name in the destination as well (assuming this verifies this BZ :)) Alex, by coincidence https://github.com/projectatomic/atomic/pull/959 was done to fix another problem and we believe this fixes this bz too. Basically if you ask to pull 'rhel7' atomic provide skopeo the fully qualified image name. See: $ sudo ./atomic pull rhel7 Pulling registry.access.redhat.com/rhel7:latest ... Copying blob sha256:8642dd241e54ecb57f49345f135e9bcedb0546e7e61c1ca4d0008a9925f50444 68.78 MB / ? [=--------------------------------------------------------------] Copying blob sha256:fdd633d880f736958e14a036256b2def325acf6b438b7c849139fe92d5cbe4ce 0 B / ? [--------------------------------------------------------------------=] Copying config sha256:a2d9f633eaabd6a5e94d16f0d0259b05a5f3081921c3ddd550897fcd7b61b5e1 0 B / 4.32 KB [---------------------------------------------------------------] Writing manifest to image destination Storing signatures 4.32 KB / 4.32 KB [===========================================================] $ docker images | grep rhel7 registry.access.redhat.com/rhel7 latest a2d9f633eaab 3 days ago 192.7 MB (In reply to Brent Baude from comment #8) > Alex, by coincidence https://github.com/projectatomic/atomic/pull/959 was > done to fix another problem and we believe this fixes this bz too. > Basically if you ask to pull 'rhel7' atomic provide skopeo the fully > qualified image name. > It works well in atomic-1.17.1-1.gitf304570.el7.x86_64 w/ skopeo-0.1.18-1.el7.x86_64, so moving the bug to VERIFIED status. *** Bug 1430706 has been marked as a duplicate of this bug. *** It also works well in atomic-1.17.2-2.git2760e30.el7.x86_64. 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:1323 |
Description of problem: Using atomic to pull images in 7.3.4, I can't see the image by atomic images list, but it's okay by docker images, in addition, to pull a image w/ simple name such as rhel7, it seems atomic will pull rhel7 from registry.access.redhat.com registry preferentially, however, finally, the docker.io/rhel7 image is pulled, it let users confuse. Version-Release number of selected component (if applicable): [root@atomic-host-test-986 cloud-user]# atomic host status State: idle Deployments: ● Atomic-7.3-20170323.0:rhel-atomic-host/7/x86_64/standard Version: 7.3.4 (2017-03-30 07:50:37) BaseCommit: 45a4dacb87c3e619fb9cae07d038b9570e95da957d94d7f6b90afcb76cef08c8 Commit: c5bfa23a3fef4655dfc0d11b2479067e359d42e5b43da9db41cd883082837ae2 OSName: rhel-atomic-host LayeredPackages: wget [root@atomic-host-test-986 cloud-user]# rpm -q atomc docker skopeo package atomc is not installed docker-1.12.6-16.el7.x86_64 skopeo-0.1.18-1.el7.x86_64 How reproducible: always Steps to Reproduce: 1. atomic pull rhel7 2. atomic images list 3. docker images 4. atomic pull registry.access.redhat.com/rhel7 5. repeat 2 6. repeat 3 Actual results: [root@atomic-host-test-986 cloud-user]# atomic pull rhel7 Pulling registry.access.redhat.com/rhel7:latest ... Copying blob sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 68.80 MB / ? [-------------------------------------=-------------------------] Copying blob sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 0 B / ? [--------------------------------------------------------------------=] Copying config sha256:41a4953dbf957cfc562935239a3153a5da6101f32fa30da7b4a506f23cfcde9d 0 B / 4.49 KB [---------------------------------------------------------------] Writing manifest to image destination Storing signatures 4.49 KB / 4.49 KB [===========================================================] [root@atomic-host-test-986 cloud-user]# atomic images list REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE TYPE docker.io/rhel7 latest 41a4953dbf95 2017-02-22 17:30 192.54 MB docker NOTE: pulling registry.access.redhat.com/rhel7:latest, but the finally pulled image is docker.io/rhel7. [root@atomic-host-test-986 cloud-user]# atomic pull registry.access.redhat.com/rhel7:latest Pulling registry.access.redhat.com/rhel7:latest ... Copying blob sha256:154dc369ca0dfabd18ddeca63a8bced0dfaefaa0b2cd7cb6ec9513423d863652 68.80 MB / ? [-------------------------------------=-------------------------] ^[[A Copying blob sha256:e6b5b6e3c1421d338b32d3c2f9fac2ab424f35857e8c89d6133b8d54f5cdad49 0 B / ? [--------------------------------------------------------------------=] Copying config sha256:41a4953dbf957cfc562935239a3153a5da6101f32fa30da7b4a506f23cfcde9d 0 B / 4.49 KB [---------------------------------------------------------------] Writing manifest to image destination Storing signatures [root@atomic-host-test-986 cloud-user]# atomic images list REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE TYPE docker.io/rhel7 latest 41a4953dbf95 2017-02-22 17:30 192.54 MB docker [root@atomic-host-test-986 cloud-user]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/rhel7 latest 41a4953dbf95 5 weeks ago 192.5 MB registry.access.redhat.com/rhel7 latest 41a4953dbf95 5 weeks ago 192.5 MB NOTE: only can see registry.access.redhat.com/rhel7 by docker images Expected results: Additional info: