Status: Closed (View Workflow)
Customer Problem: As a Quay administrator I want to allow my clients to store more than runnable container images. Given OCI artifact spec I want to be free to choose what kind of content can be stored on and served by Quay.
Goal: Make adopting OCI artifacts straightforward with quay.
User Story: As an admin of Quay, I'd like to be able to enable pre-defined and custom OCI mime-types so that I can store this content in Quay.
Default types we need to support: We need several additional OCI types to increase adoption of Quay in evolving areas such as artifact signing, helm and alternate compression schemes:
The above should be generated by all our default configs and the config editor.
The specification for creating additional media types is complete https://github.com/opencontainers/image-spec/blob/master/media-types.md
As cloud-native tooling picks up support for those mime-types, particularly helm and cosign, Quay should start accepting those types as a basis for more first-class treatment later.
Lastly, this also helps enabling experimental usage of Quay (new client-side compression algorithms) or allowing workarounds for broken clients (that send invalid mime types).
Out of scope:
- Any special treatment of these types of images, Quay should simply not reject them
- how does Clair supposed to treat custom OCI mimetypes?
- Quay by default accepts the above defined defined OCI artifact types with push / pull Operations
- Quay allows to register custom OCI media type that a customer might have but does not treat them in a special way
Acceptance / Test Criteria:
- a user is able to use helm CLI to store and retrieve charts as OCI images from Quay
- a user is able to use cosign CLI to sign an existing image in Quay and validate the image subsequently
- a user is able to push an image with zstd compression using podman (https://github.com/containers/skopeo/pull/1111)