Discussion: Media types for bundles in OCI registries
radu-matei opened this issue · comments
Nit/question: is
application/vnd.cnab.bundle.config.v1+json
redundant? We've been usingapplication/vnd.cnab.config.v1+json
internally. I can see the former being nice if we add more cnab-scoped artifact types in the future though.
is
application/vnd.oci.image.config.v1+json
an example or the only allowed alternate type? If the docker image type would be allowed as well, I suggest changing this to "(e.g.application/vnd.oci.image.config.v1+json
)" to allow room for other values.
Picking this up so that we can finalize the registry spec.
@radu-matei @jlegrone: For the bundle media type, I don't have strong opinions but we are using application/vnd.cnab.config.v1+json
in CNAB to OCI. Are there other configs we imagine we may need in the future?
@carolynvs: Full paragraph so that those reading have full context:
The
bundle.json
MUST be serialized as canonical JSON and MUST be stored in the registry as a blob. This blob MUST be referenced by its digest in an OCI manifest. The manifest media type SHOULD beapplication/vnd.cnab.bundle.config.v1+json
but MAY be a standard container image config type (application/vnd.oci.image.config.v1+json
) if the target registry does not support the CNAB media type.
I agree that we should make this less strict and accept Docker types. This allows better registry compatibility and avoids us mixing Docker (for the container images) and OCI types (for the bundle manifest and index) which some registries reject.
My suggested change:
This blob SHOULD be referenced by its digest in an OCI manifest but MAY be referenced in a Docker manifest. The manifest media type SHOULD be
application/vnd.cnab.bundle.config.v1+json
but MAY be a standard OCI container image config type (application/vnd.oci.image.config.v1+json
) or Docker container image config type (application/vnd.docker.distribution.manifest.v1+json
) if the target registry does not support the CNAB or OCI media types.
Hi folks,
Per the OCI Artifact spec for Defining a Unique Artifact Type
The following
config.mediaType
format is used to differentiate the type of artifact:
[registration-tree]
.[org|company|entity]
.[objectType]
.[optional-subType]
.config.[version]
+[optional-configFormat]
What org
will CNAB be under? It could be under deislabs
I suppose.
Also note the IANA registration process:
New artifact types SHOULD register their unique
config.mediaType
and uniquelayer.mediaType
with IANA to assure ownership of the type. [Well-known][def-well-known-types] types MUST register their uniquemediaTypes
to be published for registry consumption.
We're also working on a better collection model, as CNABs really don't fit will int OCI Index. See here for a third manifest type we're proposing.
In the meantime, the index mediaType is the best bet. Using the .v1
to v2
versioning will help with any migration in the future.
As for chicken/egg, with the exception of Docker Hub, all major registries now support OCI Artifacts. It's only recently they most started supporting index. It would be great if Docker could simply release the mediaType constraint as we've already seen, customers are placing everything in Docker Hub from VMs to dog/cat pictures by just masking them as a docker mediaType.
The org is cnab.io
, which is correlated to Linux Foundation.
@technosophos, the uniqueness is a challenge. We're trying to help other artifact owners understand the pattern and follow the leads of others. Unfortunately, just calling it application/vnd.cnab.bundle.*
implies cnab is somehow globally unique.
Do you mind following up with the IANA process to claim this mediaType
so you could claim you have taken ownership of this mediaType
?
For the larger reference manifest problem, we have some new work coming out in the next few weeks. Here's an early preview: https://github.com/SteveLasker/artifacts/blob/artifact-manifest/artifact-manifest/artifact-manifest.md