api: return imageID instead of imageName, for "Image" when Podman api is queried

[m0duspwnens]

[NO NEW TESTS NEEDED]

This PR is intended to resolve a discrepancy for the "Image" key when the Podman API is queried.

Query example:

curl --unix-socket /run/podman/podman.sock http://localhost/v4.0.0/containers/somecontainer/json | jq

The Docker API returns the imageID for Image when querying a container as seen below:

  "Image": "sha256:somehash",

When querying the Podman API, the imageName is currently being returned:

  "Image": "ghcr.io/someimage:latest",

Once the change is implemented, the imageID is returned for the Image key.

  "Image": "sha256:somehash",

Does this PR introduce a user-facing change?

Fixed: Podman API will now return the imageID instead of imageName for the "Image" key when the API is queried.

[mheon]

Tests are red, but changes LGTM otherwise

[mheon]

/approve

[vrothberg]

Here's the error:

[+0078s] not ok 414 [20-containers] GET containers/8d97d1ece10812a6e793307a813ddb4d34f0d83ecd05d1af3fbc68fffcad303b/json : .Image
[+0078s] #  expected: localhost/test/testformultitag:tag
[+0078s] #    actual: sha256:5e9e9275e4d60569c72dde5d1e31cee0795df81a386bdc325873b8ed22875bc6

[TomSweeneyRedHat]

And if it's useful, the 1043 test failure:

[+0163s] not ok 1043 [70-short-names] GET containers/51a68da6c2a640fd194c0b22f1eaaef6915bb60562717ad83ab1a56e6e14ae34/json : .Image
[+0163s] #  expected: quay.io/libpod/alpine:latest
[+0163s] #    actual: sha256:961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4

[m0duspwnens]

Do you have any guidance on the current test failures?

[jertel]

On the initial PR request, only two tests failed CI. After correcting those two tests, which were confirmed to be affected by this PR, they are now passing. However, now the sys * ubuntu-2204 root* host tests have begun failing. This PR was then updated with master, yet still they both failed, although one has different error output from the previous CI run, which makes me think they are failing for different reasons. Is there known instability with the sys * ubuntu-2204 root host tests?

[vrothberg]

Do you have any guidance on the current test failures?

That's unrelated to your changes. Apologies for the inconvenience.

I suspect that the Ubuntu tests are using a broken containers/conmon.

@lsm5 @cevich can we bump conmon to v2.1.4 in the VMs? v2.1.3 is broken.

Cc: @edsantiago

[edsantiago]

There is no conmon-2.1.4 for Ubuntu. As of yesterday, it's still 2.1.3

I've restarted the flakes. I think the only solution here is to file yet another ubuntu-is-broken issue, then add skip_if_ubuntu "FIXME: #12345 conmon signal flake" to the failing tests.

[lsm5]

It's building at https://build.opensuse.org/package/show/devel:kubic:libcontainers:unstable/conmon , so this should make progress in sometime.

[lsm5]

v2.1.4 should now be available on the kubic repo. And I see the tests are green, unless I'm looking in the wrong place.

[rhatdan]

/approve
LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: m0duspwnens, mheon, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mheon,rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vrothberg]

/lgtm

Thanks!