daemon/controller: check resolved content digest

[alicefr]

When bootc pulls a multi-arch image, the pullspec carries the manifest-list digest while bootc resolves and reports a platform-specific content digest. These two digests differ because a manifest list is an index pointing to per-platform manifests.

Previously, the code only compared ImageDigest (the platform-specific digest) against the target. When the target was a manifest-list digest, they would never match, causing the controller to consider nodes not up-to-date even though they were running the correct image.

Introduce image.InfoMatchesDigest() which accepts either digest as a match: the resolved content digest in ImageDigest, or the manifest-list digest embedded in the Image pullspec.

For example, on EKS bootc status shows:

Image: ...@sha256:ff63b... (manifest-list digest)
Digest: sha256:db1b41... (platform-specific content digest)

Both must be accepted as a match.

[alicefr]

@HarshwardhanPatil07 PTAL

[Johan-Liebert1]

When the target was a manifest-list digest, they would never match

when would this happen? I'm not aware of any path in bootc that would record the manifest list digest

[alicefr]

When the target was a manifest-list digest, they would never match

when would this happen? I'm not aware of any path in bootc that would record the manifest list digest

I have experienced this in EKS, bootc was reporting another digest then the remote one. With this patch, I have been able to test correctly the bootc-operator.

[Johan-Liebert1]

For example, on EKS bootc status shows:
Image: ...@sha256:ff63b... (manifest-list digest)
Digest: sha256:db1b41... (platform-specific content digest)

iiuc seems like the digest is still the platform specific one, but the image shows manifest list digest and not the image name, which is okay right?

[alicefr]

The Digest field (ImageDigest in the API) is the platform-specific content digest that bootc resolved, and
the Image field carries the original pullspec which includes the manifest-list digest. Both are correct.

The problem was in the comparison logic: when the BootcPool target is specified as a manifest-list digest (e.g. from a
multi-arch registry tag), the old code only compared against ImageDigest (the platform-specific one). Since the
manifest-list digest and the platform-specific digest are inherently different, the comparison would never match, making the controller think the node wasn't up-to-date.

The fix (InfoMatchesDigest) accepts either digest as a valid match: first it checks ImageDigest, and if that doesn't match, it extracts the digest from the Image pullspec and checks that too.

[Johan-Liebert1]

Still feels like there's something here that we're doing wrong. If the issue is "When operator fetches an image update/switch (gets the manifest list digest) and tries to match with bootc status and the match fails", then I think the operator should get the architecture specific digest to compare.

Since we run as a daemon, we should have access to the host architecture.

To unblock testing, this is fine for now, but I think we should give this a second thought

[alicefr]

Still feels like there's something here that we're doing wrong. If the issue is "When operator fetches an image update/switch (gets the manifest list digest) and tries to match with bootc status and the match fails", then I think the operator should get the architecture specific digest to compare.

Since we run as a daemon, we should have access to the host architecture.

To unblock testing, this is fine for now, but I think we should give this a second thought

I agree, maybe we were checking the wrong digest from the beginning. We always assumed that the digest from the remote image was the one that should have been reported by bootc.