Consistently use a string type for expectedLayerDiffIDFlag

[mtrmac]

Might be a fix for #2602 .

[mtrmac]

@edsantiago This is a guess at the problem and fix; not reproduced, untested. Filing early just in case it happened to unblock you.

[edsantiago]

Sigh, another one I can't reproduce, but with this vendored in I'm seeing a lot of:

# Error: copying system image from manifest list: reading blob sha256:25981b83f156d64ac55f45ea4c549fa54f4a27d20b4a9639a9efe965aed84617: not supported

(could be completely unrelated; could be that your PR lets things go through a little farther and then something else is breaking. I need to switch gears)

[mtrmac]

That’s … not a helpful message from c/image or c/storage. Not too likely to be directly related, but also I don’t have any idea where it is coming from.

[mtrmac]

I have confirmed that this fixes #2602, at least per the custom reproducer in #2602 (comment) ; this is ready for review.

[cgwalters]

One thing I don't understand here is what's the other code that is setting this to a Digest type? It doesn't seem to be in c/image or c/storage, but maybe I'm missing it.

[cgwalters]

Why was map[string]interface{} chosen here? It came in 15ac716f1690cb04f3694e7b295e4830217e8c62 but I don't understand why it couldn't be a structure.

[mtrmac]

See how it is used in that commit; this goes all the way back to 7426cceb6fc121882d601fdfb309e075ecd6f10d .

As for why this does not record specific fields … *shrug* it’s an escape hatch so that out-of-c/storage users can store their private data without properly maintaining a c/storage type extension or without making that data public to all c/storage users; and that’s basically what’s happening here.

[edsantiago]

Still seeing not supported and blob size mismatch but I guess one bug at a time

[mtrmac]

One thing I don't understand here is what's the other code that is setting this to a Digest type?

I don’t understand the question. The patched line is the only writer, and untrustedUncompressedDigest is a digest.Digest.

[mtrmac]

Still seeing not supported

I don’t immediately know; it’s not happening when just pulling that image from Quay.

and blob size mismatch

Looking at https://github.com/containers/podman/blob/740f1d1fc710d4560d2463b11333cc9ad68e22bd/vendor/github.com/containers/storage/pkg/chunked/storage_linux.go#L1156 , that Podman version does not include containers/storage#2130 yet, so that is expected. (I’m currently working with containers/podman#24287 .)

but I guess one bug at a time

Yes please.

[edsantiago]

It's possible that "not supported" is only showing up on boltdb tests. (All the error logs are different and it's really hard to catalogue them all). So I spent an hour and a half trying to reproduce on a boltdb setup, with local repo very close to the mirror cache, but no luck.

[edsantiago]

Hurray for stepping afk! The problem is with VFS. containers/podman#24308