Add proposal G #16
Add proposal G #16
Conversation
mfranczy
requested review from
ChaoyiHuang,
vsoch,
sudo-bmitch,
cyphar and
neersighted
as code owners
docs/proposals/PROPOSAL_G.md
Outdated
| }, | ||
| "layers": [ | ||
| { | ||
| "mediaType": "application/k8s.nfd.image-compatibility.spec.v1alpha1+json", |
There was a problem hiding this comment.
Why would nfd (or more generally, the same compatibility group) have multiple?
There was a problem hiding this comment.
It's not required, but it allows people to bring profiles defined on the artifact side.
There was a problem hiding this comment.
So the tool to parse this would need to parse the list, find three things, and then download each separately to find a profile? Wouldn't it be easier to just use the structure that I suggested in proposal F and put the profiles in sections, for only one extra API call?
There was a problem hiding this comment.
To find a profile you would have to download the artifact manifest and lookup for specific blob (could be done with help of annotations - like name). Additionally, that way we also allow people to use more than one media type (that can be different) if they require.
| Interest groups/communities are responsible to release their own media types with corresponding schemas and overall JSON structure. | ||
| Schema MUST provide attributes that will allow to express image compatibility. | ||
| Known media types SHOULD be referenced in the OCI documentation. | ||
|
|
There was a problem hiding this comment.
This looks to be exactly the same as F, but with no suggestion to structure to the artifact itself.
There was a problem hiding this comment.
So after all it's not the same :)
There was a problem hiding this comment.
It's just details that are different - the overall media type (for a community) -> artifact is the same I think.
There was a problem hiding this comment.
Right. But that's a detail I wanted to highlight and that brings a topic to discuss. The artifact indeed is the same.
|
|
||
| ## Tools implementation | ||
|
|
||
| Tools that implement image compatibility use cases MUST follow the schema provided by the media type. |
There was a problem hiding this comment.
In practice this means a 1:1 mapping of tools to media types... :/
There was a problem hiding this comment.
Only when we talk about attributes. IMO we should avoid adding more to spec than a media type allows. That would guarantee to have the same expectations from spec side across different implementations. If it's required to add something extra (like schema graphs, compatibility relations) we should use annotations.
There was a problem hiding this comment.
But if there is no definition of the structure, you could have entirely different json blobs and they would both be valid, but (in real world cases) only supported by whatever tooling the community provides. If a community makes a nice validation tool for the structure, nobody else can use it except for them, for example.
There was a problem hiding this comment.
Definition of the structure comes from the media type. This is the same as for all OCI media types.
https://github.com/opencontainers/image-spec/blob/main/media-types.md
All the allowed properties are tight to specifc type.
IMO it would be wrong to force the same structure across different media types.
There was a problem hiding this comment.
We can have one media type for the compatibility spec and add information about source (like k8s, hpc etc.) over media type parameters.
That way we provide one spec under one media type across different compatibility keys providers.
That could look like this
"mediaType": "application/vnd.oci.image-compatibility.spec.v1+json; labels=k8s-nfd" # only k8s nfd labels
"mediaType": "application/vnd.oci.image-compatibility.spec.v1+json; labels=hpc" # only hpc labels
"mediaType": "application/vnd.oci.image-compatibility.spec.v1+json; labels=k8s-nfd,hpc" # combined labels
"mediaType": "application/vnd.oci.image-compatibility.spec.v1+json" # ambiguous labels
(We don't have to combine labels, but I guess the general idea is clear. Also we can name the parameter differently.)
The parameter is optional, but necessary for tools to understand compatibility data.
There was a problem hiding this comment.
Nevermind, OCI doesn't support media type parameters.
Signed-off-by: Marcin Franczyk <[email protected]>
There was a problem hiding this comment.
LGTM as a complete proposal. Overall I'm not a fan, and would prefer we went the other direction, having NFD create their own artifact with their own media type. And after a few projects either adopt NFD's format, or create competing artifacts, then we consider consolidation. Or at least it should be NFD coming to OCI with the proposal rather than OCI going to NFD.
|
|
||
| ## Artifact Manifest | ||
|
|
||
| An artifact manifest MAY contain multiple blobs with different or the same media types, but MUST contain at least one. |
There was a problem hiding this comment.
If you wanted to package multiple versions of these into a single blob, jsonl, aka JSON Lines may be a good option.
I agree with that. That's why I have decided to close the PR as it's not OCI centric which leads me to the thought that this proposal doesn't make sense within OCI. |
This proposal is very simple, it only defines a new compatibility artifact and recommends creating an index of known media types created by communities. Delegates the creation of the schema and overall json structure to the community. Finally, it provides some implementation recommendations.