Version LABEL may supersede the Version LABEL of the parent image when using 'atomic verify'

[miabbott]

When using atomic verify I expected to get a clean output for individual images contained in a layered image, where each image had its own version information. For example:

# atomic verify -v rhel7/rhel-tools

rhel7/rhel-tools contains the following images:

     Local Version                  Latest Version                  
     -------------                  --------------                  
     rhel7/rhel-tools-7.2-17        rhel7/rhel-tools-7.2-17         
     rhel7/rhel-7.2-46             rhel7/rhel-7.2-46              *

     * = version difference

However, I can build a layered image that has it's own Version LABEL which causes the Version LABEL of the parent image to be superseded.

# cat test_version/Dockerfile 
FROM registry.access.redhat.com/rhel7
LABEL Version="9000"
CMD ["/bin/bash"]

# docker build -t rhel7_test_version test_version/
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM registry.access.redhat.com/rhel7
 ---> bf63a676257a
Step 2 : LABEL Version "9000"
 ---> Running in c4b4b2ed5de7
 ---> 432f81ffd5af
Removing intermediate container c4b4b2ed5de7
Step 3 : CMD /bin/bash
 ---> Running in fbdcdd267791
 ---> 6869ffffa909
Removing intermediate container fbdcdd267791
Successfully built 6869ffffa909

# docker images | grep version
rhel7_test_version                                           latest              6869ffffa909        5 seconds ago       203.2 MB

# atomic verify -v rhel7_test_version

rhel7_test_version contains the following images:

     Local Version                  Latest Version                  
     -------------                  --------------                  
     rhel7/rhel-9000-46             rhel7/rhel-9000-46              

     * = version difference

In the above example, I expected the parent image to be represented correctly as in the first example, since they both use the same base image.

[miabbott]

This was seen using atomic-1.9-4.gitff44c6a.el7.x86_64 and docker-1.9.1-25.el7.x86_64 on RHELAH

[rhatdan]

The idea would be to update the base image to a newer image then the atomic verify should come back and tell you to rebuilt your layered image using the new base image.

[miabbott]

I tried to replicate that scenario below and I didn't get the expected results.

1. Pull old version of rhel7
2. Tag it as latest
3. Build layered image
4. Delete the latest tag
5. Run atomic verify
6. Pull real rhel7:latest
7. Run atomic verify

I would have expected one of those instances of atomic verify to come back and tell me that the base image was out of date, but that was not the case.

Maybe I am assuming atomic verify works differently than it does?

# docker pull registry.access.redhat.com/rhel7:7.2-44
18c92348de36: Download complete 
Status: Downloaded newer image for registry.access.redhat.com/rhel7:7.2-44
registry.access.redhat.com/rhel7: this image was pulled from a legacy registry.  Important: This registry version will not be supported in future versions of docker.

# docker tag registry.access.redhat.com/rhel7:7.2-44 registry.access.redhat.com/rhel7:latest 

# docker images
REPOSITORY                         TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
registry.access.redhat.com/rhel7   7.2-44              18c92348de36        6 weeks ago         203.2 MB
registry.access.redhat.com/rhel7   latest              18c92348de36        6 weeks ago         203.2 MB

# cat test_version/Dockerfile 
FROM registry.access.redhat.com/rhel7
LABEL Version="9000"
CMD ["/bin/bash"]

# docker build -t rhel7_test_version test_version/
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM registry.access.redhat.com/rhel7
 ---> 18c92348de36
Step 2 : LABEL Version "9000"
 ---> Running in b0f953f7a1ab
 ---> 606f4f69fad1
Removing intermediate container b0f953f7a1ab
Step 3 : CMD /bin/bash
 ---> Running in 1b804ca023af
 ---> 6b78ddcdcdf9
Removing intermediate container 1b804ca023af
Successfully built 6b78ddcdcdf9

# docker images
REPOSITORY                         TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
rhel7_test_version                 latest              6b78ddcdcdf9        8 seconds ago       203.2 MB
registry.access.redhat.com/rhel7   7.2-44              18c92348de36        6 weeks ago         203.2 MB
registry.access.redhat.com/rhel7   latest              18c92348de36        6 weeks ago         203.2 MB

# docker rmi registry.access.redhat.com/rhel7:latest
Untagged: registry.access.redhat.com/rhel7:latest

# atomic verify -v rhel7_test_version

rhel7_test_version contains the following images:

     Local Version                  Latest Version                  
     -------------                  --------------                  
     rhel7/rhel-9000-44             rhel7/rhel-9000-44              

     * = version difference

# docker pull registry.access.redhat.com/rhel7
Using default tag: latest
95612a3264fc: Download complete 
Status: Downloaded newer image for registry.access.redhat.com/rhel7:latest
registry.access.redhat.com/rhel7: this image was pulled from a legacy registry.  Important: This registry version will not be supported in future versions of docker.

-bash-4.2# atomic verify -v rhel7_test_version

rhel7_test_version contains the following images:

     Local Version                  Latest Version                  
     -------------                  --------------                  
     rhel7/rhel-9000-44             rhel7/rhel-9000-44              

     * = version difference

# docker images
REPOSITORY                         TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
rhel7_test_version                 latest              6b78ddcdcdf9        About a minute ago   203.2 MB
registry.access.redhat.com/rhel7   latest              95612a3264fc        9 days ago           203.3 MB
registry.access.redhat.com/rhel7   7.2-44              18c92348de36        6 weeks ago          203.2 MB

[rhatdan]

@baude PTAL

[rhatdan]

Cleaning up atomic issues.

@miabbott @baude is this still an issue, or is it fixed in the current release?

[miabbott]

@rhatdan This is still an issue with HEAD of master