Show tag image for workload in list-images

[hiddeco]

Fixes #847

Before this change the comparison to list an image as being used by the workload was purely based upon the tag name. We now also check if the digest of the image matches the one in our image cache.

In addition, if we are unable to match the image of the workload to a tag and digest in our image cache, we still list the name of the tag (as we have no other data available), but with a question mark added as a prefix (?->).

[squaremo]

The image tagged latest is not necessarily the one that's running if you omit the tag, so I think this would be misleading.

[hiddeco]

@squaremo can you give an example of where this would not be the case? As this is exactly what I observed from both Docker and Kubernetes.

❯ docker pull hiddeco/bogus
Using default tag: latest
Error response from daemon: manifest for hiddeco/bogus:latest not found
❯ kubectl describe deployment nginx-deployment
<metadata snip>
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        hiddeco/bogus
❯ kubectl get pods
NAME                                 READY   STATUS                       RESTARTS   AGE
nginx-deployment-69c9678764-q96zx    0/1     ErrImagePull                 0          73s
❯ kubectl describe pod nginx-deployment-69c9678764-q96zx
<snip>
Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Normal   Scheduled  8m7s                   default-scheduler  Successfully assigned default/nginx-deployment-69c9678764-q96zx to minikube
  Normal   Pulling    6m38s (x4 over 8m6s)   kubelet, minikube  Pulling image "hiddeco/bogus"
  Warning  Failed     6m36s (x4 over 8m3s)   kubelet, minikube  Failed to pull image "hiddeco/bogus": rpc error: code = Unknown desc = Error response from daemon: manifest for hiddeco/bogus:latest not found

[squaremo]

That's what happens if there's no image hiddeco/bogus already on the host. If there is, one is selected (the most recent pulled or built I think).

E.g., if you have a manifest with just weaveworks/flux, and you build the flux image using the same Docker daemon as Kubernetes is using, the pod will run despite the fact that there's no weaveworks/flux:latest image on DockerHub.

[hiddeco]

E.g., if you have a manifest with just weaveworks/flux, and you build the flux image using the same Docker daemon as Kubernetes is using, the pod will run despite the fact that there's no weaveworks/flux:latest image on DockerHub.

And the list will not display the image you are currently running because we do not have it in our cache (which does not seem misleading to me), I am actually running my Flux pod this way.

How would you like it to be presented in case the cluster is running an image we can not find in our cache? Because given your comments, I think that's the actual issue that needs to be solved.

[squaremo]

And the list will not display the image you are currently running because we do not have it in our cache (which does not seem misleading to me)

But it would line it up with a :latest image if there were one, no? And that is not necessarily the same image. blank does not equal :latest.

[hiddeco]

But it would line it up with a :latest image if there were one, no? And that is not necessarily the same image. blank does not equal :latest.

But this is no different from how it works at the moment? If you overwrite the tag in your local Docker daemon (say :build) and the registry also has a :build, list-images will also point towards this cached version (from the registry).

[squaremo]

But this is no different from how it works at the moment? If you overwrite the tag in your local Docker daemon (say :build) and the registry also has a :build, list-images will also point towards this cached version (from the registry).

True, that's a problem now, we assume tag equality means image equality, and that's not always right.* This would add to the problem by assuming an extra thing, that a missing tag is the same as :latest.

*It's difficult to go on anything other than tag equality, because we don't in general have the image digests for what's actually running, and even if we did, they could be different per pod.

How would you like it to be presented in case the cluster is running an image we can not find in our cache? Because given your comments, I think that's the actual issue that needs to be solved.

That's part of the issue -- the image with no tag will never be in the image database. I honestly don't know what is a good way to illustrate either of these situations. Maybe just a question mark instead of an arrow.

[squaremo]

OK, being literal about the issue as reported, what I suggest is this: if the current image doesn't have a tag, then output a row with a question mark and "point" at that. E.g.,

weave:deployment/flux   flux       weaveworks/flux
                                   '->  (untagged)      ?
                                        1.12.2          08 May 19 10:30 UTC
                                        1.12.1          25 Apr 19 10:36 UTC
                                        1.12.0          11 Apr 19 14:59 UTC
                                        1.11.1          01 Apr 19 18:59 UTC
                                        1.11.0          13 Mar 19 09:40 UTC
                                        1.10.1          13 Feb 19 17:51 UTC
                                        ...

[squaremo]

If at some point we gather the digest given in the manifest, then we can indicate when that is a match with an image in some other way, too.

[hiddeco]

@squaremo it now looks like this

default:deployment/flux-helm-operator  flux-helm-operator  weaveworks/helm-operator       
                                                           |   0.9.0                      08 May 19 10:42 UTC
                                                           |   0.7.1-rebuild              19 Apr 19 16:34 UTC
                                                           |   0.8.0                      11 Apr 19 15:35 UTC
                                                           |   0.7.1                      27 Mar 19 10:11 UTC
                                                           |   0.7.0                      25 Mar 19 11:05 UTC
                                                           |   0.6.0                      07 Feb 19 10:54 UTC
                                                           |   0.5.3                      14 Jan 19 18:37 UTC
                                                           |   0.5.2                      20 Dec 18 10:33 UTC
                                                           |   0.5.1                      21 Nov 18 11:11 UTC
                                                           |   0.5.0                      14 Nov 18 14:48 UTC
                                                           '-> latest                     ?

[squaremo]

@squaremo it now looks like this

default:deployment/flux-helm-operator  flux-helm-operator  weaveworks/helm-operator       
                                                           |   0.9.0                      08 May 19 10:42 UTC
                                                           |   0.7.1-rebuild              19 Apr 19 16:34 UTC
                                                           |   0.8.0                      11 Apr 19 15:35 UTC
                                                           |   0.7.1                      27 Mar 19 10:11 UTC
                                                           |   0.7.0                      25 Mar 19 11:05 UTC
                                                           |   0.6.0                      07 Feb 19 10:54 UTC
                                                           |   0.5.3                      14 Jan 19 18:37 UTC
                                                           |   0.5.2                      20 Dec 18 10:33 UTC
                                                           |   0.5.1                      21 Nov 18 11:11 UTC
                                                           |   0.5.0                      14 Nov 18 14:48 UTC
                                                           '-> latest                     ?

OK -- as before, latest may be tag that is in the repo and isn't known to be the image being run. So I would prefer a different placeholder when the configured image doesn't have a tag.

[hiddeco]

That's what's in the code:

e0a7271#diff-1400f8d8bf6b4557b8199aaa5f25d330R142

The deployment from my example is actually running from the latest tag.

[squaremo]

The deployment from my example is actually running from the latest tag.

Ahhhh I see! But we exclude the latest image metadata from the results, so it has to report ? for the timestamp?

[hiddeco]

But we exclude the latest image metadata from the results, so it has to report ? for the timestamp?

If someone is now running a tag that we do not have in our cache, we still display the tag and a question mark (because we have no metadata for that tag), in case the current tag is empty, we replace it with (untagged).

[squaremo]

Good tying up of a loose end -- thanks Hidde 🍍