I figured it'd be more polite to open a new issue about this rather than spawn two conversations from #164 so I'm quoting from that.

For example, if I'm deploying haproxy:2.2.14 the maintainers will periodically rebuild their image when their base image changes (e.g. they rebuild 2.2.14 because of a CVE in a dependent library like SSL) and they'll release a new "version" of 2.2.14 with the same exact tag but with a different hash. Can/does flux2 pick that up and deploy the new image

This is not possible with any version of Flux today, since Flux works from git, there is no change to apply, and since the image metadata is the only place where Flux could look to know that something has changed, and Flux no longer does anything with image metadata as it is commonly rate limited and expensive to pull the metadata from each image tag one by one, there would not currently be any way for Flux to know if something has changed in the manner you are describing.

I've been thinking about this a bit more. As a user of flux v1 I very much understand the rate limiting issues that were arising. However, tags are mutable and (from my understanding) it is considered a good security practice to pin to digests. Indeed, if I have two nodes that run haproxy it is possible that I could end up deploying two different versions of haproxy:2.2.14 if I do not use digest pinning. (I'm going to keep using haproxy as an example. Sorry.) While I don't want to discourage anyone from just putting into their yaml files a tag and being happy, I would like request support for digest pinning.

Here's how I figure it can work:

1. I put Image: haproxy:2.2.14@sha256:792ac7e9a42dcb028039bd6ec02cfdde75e94980652121e1fe557e7cf8b847bb in my configuration.
2. Flux says "hey you want 2.2.14, let's go check the digest for 2.2.14 and see if it matches what is pinned".
3. It matches! Yay, leave it alone.
4. It does not match. Push a commit with the new/correct digest and update the cluster.

Getting the correct digest fortunately only requires one call to the registry for the one tag and not repeated calls for all tags and also does not need to be made if the flux user isn't using digest pinning. It's as simple as:

REGISTRY=https://index.docker.io/v2
REPO=library
IMAGE=haproxy
TAG=2.2.14
TOKEN=$(curl -sSL "https://auth.docker.io/token?service=registry.docker.io&scope=repository:$REPO/$IMAGE:pull" | jq --raw-output .token)

curl --head -L -H "Accept: application/vnd.docker.distribution.manifest.list.v2+json" -H "Authorization: Bearer ${TOKEN}" "$REGISTRY/$REPO/$IMAGE/manifests/$TAG" | grep "Docker-Content-Digest"

> Docker-Content-Digest: sha256:792ac7e9a42dcb028039bd6ec02cfdde75e94980652121e1fe557e7cf8b847bb

I don't feel like this is outlandish since this is basically the same support that dependabot has:

• How does the docker support recognize new versions? dependabot/feedback#129 (comment)
• https://dependabot.com/blog/dependabot-now-supports-docker/

However, I do know that this has been requested a few times on the v1 repository and rejected. It's ok with me if you don't want to adopt this for v2 but if I don't ask then I can't receive. :)