[do-not-merge] Print as much as we can in 'inspect' even for non-image artifacts.

[jankaluza]

This commit removes the check for MediaTypeImageConfig MediType from Inspect function. Instead, it lets the existing code to parse the OCI Config blob and print the ImageInspectInfo.

For non-image artifacts, this info can be incomplete, but still valid. If invalid config is found, the Unmarshal returns an error.

Resolves: #1933

[jankaluza]

I will have to do this change in c/image. Just testing it here.

[mtrmac]

Thanks!

For non-image artifacts, this info can be incomplete, but still valid.

I don’t think that’s very likely; the fields are fairly image-specific.

And, fundamentally, it’s just not valid to randomly read JSON fields from an entirely unknown data format and assume their meaning is consistent with images. I think such code is a forward-compatibility risk.

As is, out of the 12 items in current output, there are about 3 that are relevant to OCI artifacts in general, without specific support for a specific artifact MIME type.

---

The larger context of handling OCI artifacts with skopeo inspect is that the current output format is a historical accident and IMHO a dead end; if we are adding OCI artifacts, it should be in some other UI and output format. Consider:

• The current output, by default, includes a tag list. That’s entirely unrelated to the single image being inspected, it can be rather costly (for build systems which assign a tag to every build, many thousands of items and dozens of round-trips), and it’s very unlikely that users would want both information about a single image and a tag list at exactly the same time.
• The current output mixes data about the whole possibly multi-platform image (e.g. the digest, and repo name [the repo name is pointless anyway]) and a single per-platform instance.
• Users probably need a way to ask “what is this? Multi-platform image / Single-platform image / artifact / (other???)”. There is no way to answer that now.
• The very first question about an OCI artifact needs to be “what is the artifact’s MIME type?”
• There’s a long-standing need to list the platforms included in a multi-platform image; currently users do --raw and parse the OCI index because inspect does not provide the necessary format abstraction.

Hence I’m thinking about something like #1283 . I don’t have much of a design in mind, but I feel fairly confident there’s ~no value in adding support for OCI artifacts to the current format.

[jankaluza]

@mtrmac , Thanks for your message. You are absolutely right that this needs to be reworked. I also admitted that on a stand-up yesterday and started reading more about OCI artifacts this morning.

As I understand it, the way forward is probably redesigning the skopeo inspect in some backwards compatible way (adding new options to existing inspect or even new skopeo command, for example skope describe?) to:

• Add support for inspecting whole Image Index without resolving it to specific Image Manifest. Still print the output in user-friendly format (one can use --raw to get the raw data).
• In case of unknown manifest.artifactType / manifes.config.mediaType, only show the artifactType / mediaType and suggest using the --raw?
• Add a way to easily add new mediaType parsers for different artifacts in code.
• Not proactively try to list the repoTags, since this is expensive call and might not be supported by all the registries (at least it seems like that from code). New skopeo command could be added to support that in the future?
• Add support for inspecting whole tag by printing all the digests in a tag. Probably add --resolve option, which tries to resolve those digests to either Image Manifest or Image Index and show the same output as if they were passed to that new inspect command.

I think something like that would definitely make the skopeo more predictable to use. I'm not sure how aligned is this plan with RUN-2712, but I like it more than changing the current "inspect" in the backward-incompatible way. What do you think?

[mtrmac]

• Add support for inspecting whole Image Index without resolving it to specific Image Manifest. Still print the output in user-friendly format (one can use --raw to get the raw data).

(In general, I think of --raw as a last-resort escape mechanism. skopeo inspect, or some future variant of it, should expose the information that makes sense in a single stable format, to make it easy to write scripts, and without users having to understand the details of the underlying format (… much; the design assumptions always leak through abstractions).)

• In case of unknown manifest.artifactType / manifes.config.mediaType, only show the artifactType / mediaType and suggest using the --raw?

Ultimately, users can either write their own consumer, or script something using skopeo copy $src dir:…, and then they can do whatever they want with the artifact. Consuming the artifact is not a job of skopeo inspect.

• Add a way to easily add new mediaType parsers for different artifacts in code.

Maybe? Generally Skopeo has been a very thin wrapper over c/image, and Skopeo-specific features tend to suffer. What would the artifact-specific parser do?

(Well, there is the current Podman mechanism of application/vnd.unknown.artifact.v1 where we could list the file names… which are otherwise visible in LayersData.)

• Not proactively try to list the repoTags, since this is expensive call and might not be supported by all the registries (at least it seems like that from code). New skopeo command could be added to support that in the future?

skopeo list-tags already exists.

I think something like that would definitely make the skopeo more predictable to use. I'm not sure how aligned is this plan with RUN-2712, but I like it more than changing the current "inspect" in the backward-incompatible way. What do you think?

I’d start with (some variant of / name of) inspect --top-level which reports something sensible and forward-looking for all of (artifact, index, manifest), so that we can add features and fields to it later. We don’t need to report details of specific artifact types, or deep details of indices, in a first version, we just need to make it possible to add in the future.

For many artifacts, the only things we can reasonably report without building specific parsers is the MIME type, and config/layer blob details, and I think that’s perfectly fine. Anyone consuming a specific MIME type will probably need a tool to do that, and that tool can also provide a specific “inspect” feature; that doesn’t strictly need to exist in Skopeo.

Skopeo does need to provide a way to answer “I have this repo:tag; what is this thing?”.