Extended SystemContext to include VariantChoice.#753
Conversation
Like ArchitectureChoice and OSChoice, the user has a choice of architecture variant that can be used. If VariantChoice is blank any variant can be used. Signed-off-by: Daniel Black <daniel@linux.ibm.com>
| } | ||
| } | ||
| return "", fmt.Errorf("no image found in manifest list for architecture %s, OS %s", wantedArch, wantedOS) | ||
| return "", fmt.Errorf("no image found in manifest list for architecture %s(variant \"%s\"), OS %s", wantedArch, wantedVariant, wantedOS) |
There was a problem hiding this comment.
nit, could you add a space after the %s and before the new paren? %s (variant
|
Some unhappy tests at the moment |
mtrmac
left a comment
There was a problem hiding this comment.
Thanks!
- The *
Choiceoptions are overrides; first we should implement the default (choosing the right variant for the current runtime) - This should be implemented for
manifest/oci_index.goas well. - … and
copy.CheckImageDestinationForCurrentRuntime* (after #752 ). - … so, the runtime variant detection, compatibility rules, overrides and matching logic should probably be factored out into a shared helper now that it is bigger.
|
The test failures are unrelated, should be eventually fixed in #744 and https://github.com/containers/skopeo/pull/760/files . |
Is including https://github.com/containerd/containerd/blob/master/platforms/cpuinfo.go#L76 exposed as the API acceptable?
Quite right. Is in the spec
Thanks for the heads up, I hadn't checked PRs.
Like https://github.com/containerd/containerd/blob/master/platforms/compare.go ? |
It’s not like https://github.com/opencontainers/image-spec/blob/master/image-index.md is all that specific about the details. That’s as good a starting point as any other, I guess. (It does vaguely feel that user-space code should be able to detect CPU variants without OS help via
(We’ve found it difficult to keep APIs stable in c/image, so unless strictly necessary, this shared implementation etc. should be an either private within some package, or an internal subpackage (e.g. c/image/internal/…). With an internal-only API, the API design should be correct but is not that much of a concern for it to be long-term extensible and stable.) I’m not 100% sure how the compatibility checks (that v6 images can be run on v8 systems, and that v8 images are preferred to v6 images on such systems) should be structured in the API, but, given the above, possibly.
Form a quick skim that seems rather over-engineered ( (The |
|
For the record, another attempt is in #786 . |
|
This functionality was added in #854. |
Like ArchitectureChoice and OSChoice, the user has a choice of architecture variant that can be used.