Hi Mat,

would it help to introduce a new flag (e.g. --show-multiarch) printing the image info as a json list instead of a dictionary? You could then decide based on the list size: size(list) == 1 => single-arch, size(list) > 1 => multi-arch.

Sure, it does not necessarily have to be the same command as I pasted above. But there is one important note - the expectation here is that *exactly* the same command works (i.e. does not do `exit 1`) for both single-arch and multi-arch release image.

Let me explain the reasoning... In the AI project we now allow users to bring OCP release in the form of "old" single-arch or "new" multi-arch. But as it's the user bringing the release image, we don't know which one it is. Therefore, we wanted to do `oc [...]` in order to know whether the image is single- or multi-arch.

What we hit currently is that `oc image info -o json` gives a healthy output for single-arch image, but for multi-arch image it does `exit 1` and prints a bunch of text. The last part is important here - it is very easy for human to parse the error and realize we are dealing with multiarch, but from the code perspective we can't really do a string matching for "contains multiple images" in stderr

This issue was reported almost two years ago in https://bugzilla.redhat.com/show_bug.cgi?id=1883605 and moved as an RFE under https://issues.redhat.com/browse/WRKLDS-222.

Hi,

Log shown below does not actual output, it is error message. That's why, it disregards the output flag if the image is multiarch image(more info: https://github.com/openshift/oc/blob/e13cfc9609424b4f0cf22fe73e7ed7b0b59f9a27/pkg/cli/image/info/info.go#L163-L170).

"error: the image is a manifest list and contains multiple images - use --filter-by-os to select from:

  OS            DIGEST
  linux/amd64   sha256:cd6bd311612b3d4448457f5a68924216b087b937aa0f565cbfe4a8a42ecb6007
  linux/ppc64le sha256:6442ff2b7be3659424af383502006562c8a5753cefd4fc130626af98ad6d5946
  linux/s390x   sha256:ab0a0d47911b4776e7a1978cbc66ef80245b73f529f8b5f6ad29b729702c172b
  linux/arm64   sha256:e348c7a54f422eb3f1b5ad1cf21e332332b67327843099bc3b2ab62bc1114eff
"

`oc image info` is designed to show only one image info per request and that's why if command is executed for multiarch image, it forces user to select one of images embedded in multiarch image.

I totally understand the problem you have but what is the expected output format for multiarch images?, you are requesting image info for this image "quay.io/openshift-release-dev/ocp-release:4.11.0-0.nightly-multi-2022-07-19-022323" but you'll get a list of image infos including "sha256:cd6bd311612b3d4448457f5a68924216b087b937aa0f565cbfe4a8a42ecb6007", etc.?

I'd not consider this as a bug but can be discussed for new feature. Isn't it possible to check the error message and identify multiarch or not according to it?

Thanks.

Hey, sure thing, I agree it's something very close to RFE rather than bug so I'm not really fighting for the classification here. We have the current behaviour as below

1) `oc image info -o json` for single-arch image returns a valid content
2) `oc image info -o json` for invalid image returns an error
3) `oc image info -o json` for multi-arch image returns an error

>Isn't it possible to check the error message and identify multiarch or not according to it?

Because (2)+(3), multi-arch images from the code perspective are behaving like invalid images, the error codes for (2) and (3) above are the same. We could technically do regex matching over stderr.output but this is just ugly and quite an antipattern. If the error code returned was different, we could already do something with it. But now the only way to detect is goes down to doing something we can't really in our code (TBH, I'm not going to get a positive review on a codebase that matches strings from error messages)

>I totally understand the problem you have but what is the expected output format for multiarch images?

Assuming I'm just an end-user calling `oc image info -o json` over multiarch image, I'd assume something else than error. Maybe output with a list of manifest? Given that multiarch image is []ManifestList, `oc image info` returning the list of manifests sounds reasonable to me. Anyway, I'm not pushing for any specific interface here. The end goal for me is to have ability to use `oc [...]` in order to get all the architectures and respective SHAs from the multiarch image in a programmatic way (i.e. without manually parsing stderr strings)

oc version --client
Client Version: 4.12.0-0.nightly-2022-08-12-053438
Kustomize Version: v4.5.4

oc image info -o json quay.io/openshift-release-dev/ocp-release@sha256:a4a9636e62c3dd7a13f416d726c2f0a940894b8810fa8365a076b192689fa00f --show-multiarch 
Warning: the default reading order of registry auth file will be changed from "${HOME}/.docker/config.json" to podman registry config locations in the future version of oc. "${HOME}/.docker/config.json" is deprecated, but can still be used for storing credentials as a fallback. See https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md for the order of podman registry config locations.
[
  {
    "name": "quay.io/openshift-release-dev/ocp-release@sha256:a4a9636e62c3dd7a13f416d726c2f0a940894b8810fa8365a076b192689fa00f",
    "digest": "sha256:24ef91279747beddd4822a79d087752efb1914bcddfd6c237a3bfcee2bd4edf0",
    "contentDigest": "sha256:24ef91279747beddd4822a79d087752efb1914bcddfd6c237a3bfcee2bd4edf0",
    "listDigest": "sha256:a4a9636e62c3dd7a13f416d726c2f0a940894b8810fa8365a076b192689fa00f",
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
    "layers": [
      {
        "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
        "size": 78433080,
        "digest": "sha256:f70d60810c69edad990aaf0977a87c6d2bcc9cd52904fa6825f08507a9b6e7bc"
      },
......

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.12.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:7399