We should only do "docker pull" when images for that tag are not present

[LalatenduMohanty]

Refer #45

If docker images are present for a particular tag and user is asking for that tag images we should not do docker pull and wait for the command to say the image is up to date.
Because

• Even if the images are present for a tag and we still do docker pull for that tag, it takes 4 - 5 seconds to say image is up to date. So for 5 images it can save some time for the user.
• We should not depend on docker pull command to tell us whether we have images , but the code should figure out the same by itself locally.

[praveenkumar]

@LalatenduMohanty Long back I had discussion with @navidshaikh about same and what if same tag updated so user doesn't have updated tag images present in the box. docker pull helps us to make sure always images is up to date with a particular tag. We had this issue in our CDK during 2.0 release when tag got update and we were able to figure out what went wrong.

[navidshaikh]

what if same tag updated so user doesn't have updated tag images present in the box.

+1

docker allows to re-tag an existing container image with new contents, giving possibilities of different contents with similar name (name:tag) present at different locations (docker registry, local).
IMO, trading time delay for verifying desired contents of an image:tag by docker is better option than assuming image is requested one by just checking its name:tag.

[navidshaikh]

@vbatts: would you like to chime in this topic? Is there any better option to verify the contents of local image with the one present at docker registry ?

[vbatts]

I don't have a ton of context for this discussion, but the mechanics of checking whether a remote image:tag may be updated, sounds like the domain of projectatomic/skopeo /cc @runcom

[runcom]

afaict even with skopeo the network is the bottleneck there (the 4.-5 seconds) because in order to verify an image (and all its layers) is update we need to make various operation against the registry (retrieving the manifest, parsing it , play with layers checking. ..)
I can have a better look at this tomorrow but to my testing, even in skopeo, contacting the Docker Hub is really slow, even when just doing plain curl calls.

[praveenkumar]

Thanks @runcom for you feedback.

[praveenkumar]

Looks like we are done with discussion on this topic and if a image update/or-not docker will always fetch from network to verify the image nothing local available. If we are sure about tag will not change then something we can do locally like
"$(docker images -q myimage:mytag 2> /dev/null)" == ""