Artifact spec additions #770
Conversation
Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>
| While OCI container images have ordinal layers, supporting overlaying of a unified file system, new artifact authors MAY define how they persist their layers, which may be individual files, or collections of files. The tooling specific to that artifact type owns the processing of the files and how they are extracted on the client. | ||
|
|
||
| The [layer mediaType descriptor in the OCI Image spec](https://github.com/opencontainers/image-spec/blob/master/manifest.md#image-manifest-property-descriptions) identifies the `mediaType` MUST support one of the existing layer formats. | ||
|
|
There was a problem hiding this comment.
Question! So I'm allowed to do whatever I like for the config mediaType, but then in the layers list, it MUST be one that has been pre-approved? Or is layer formats referring to the array (and not the objects themselves?)
There was a problem hiding this comment.
Great clarification. A new artifact tool should NOT have to support all media types. If they want to support just application/vnd.cncf.helm.chart.v3+tar, that should be fine.
I'll fix it.
There was a problem hiding this comment.
If I'm deploying a registry, am I allowed to create my own mediaType for an artifact? (e.g., application/vnd.dinosaur.dump.v1 or would I need to use only "one of the existing layer formats?"
There was a problem hiding this comment.
(that's clarification for what I was asking ☝️ )
There was a problem hiding this comment.
Open for debate - media type constraints should be left to registry implementors.
I don't know if the reference implementation should include a default validator with a configurable list of valid types.
/cc @yuwaMSFT2
| ## Layer mediaTypes | ||
|
|
||
| While OCI container images have ordinal layers, supporting overlaying of a unified file system, new artifact authors MAY define how they persist their layers, which may be individual files, or collections of files. The tooling specific to that artifact type owns the processing of the files and how they are extracted on the client. | ||
|
|
There was a problem hiding this comment.
Here is sounds like I have freedom to define custom types for the layers? And then it follows that with custom content types, the distribution spec doesn't have to server containers at all?
There was a problem hiding this comment.
The custom layer types are still layers. What I'm trying to say here is they don't have to culminate in a unified file system where all the layers overlay each other. They can be completely separate collections the artifact tool can extract as they wish. A new artifact may extract layer0 into the current directory, while it might extract layer1 into a per-user config directory.
My next round is to do a PR on the distribution spec. What this should be conveying is distribution would accept and server layers. As long as it's a blob, like using the ORAS (https://github.com/deislabs/oras/) client, the registry shouldn't care.
Does that clarify it?
There was a problem hiding this comment.
Yes I understand that bit - and maybe my question would be better asked on your next PR to the distribution spec. What I am curious about is if the user is allowed custom mediaTypes (for example, docs) to be served in an image-spec (for download / otherwise handling by some client) then what is stopping someone from only serving (non container layer) artifacts in an image spec served by a registry? Technically, couldn't a registry exclusively serve one or more types, none of which are filesystem / layer related at all?
There was a problem hiding this comment.
Yes. The artifact registry enhancements don't "judge" what's being saved, as long as they follow some basic semantics to be reasoned over. For instance, if a team was doing some work and wanted to store foo artifacts in a registry, leveraging all the investments made in that PaaS or product; and either don't save any images, or they choose to save them in a different registry instance, have at it.
There was a problem hiding this comment.
That's really neat :) It makes the spec useful beyond what it was originally intended for.
Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
|
@SteveLasker is this PR still needed, as artifacts has become its own thing? |
|
house cleaning |
Add spec enhancements to support new registry artifact types.
Spec focuses on
manifest.config.mediaTypeas the means to identify the new artifact types.Changes FAQ to future work on distribution to the OCI distribution spec