Epic Goal

• Lay the foundation for Quay to be a general artifact store

Why is this important?

• As the OCI spec has evolved, Quay now has the ability to introduce first class support for new artifact types like ML/LLM models. As we see across the container registry field, the future of registries is now general purpose artifact storage. We currently have a proof of concept plugin system that lays the groundwork for Quay to one day support artifacts that require their own API and metatada, such as Helm Charts, npm (nodeJS), Maven (java), pypi (Python), conda (OS), cran (R), sbt (Scala), nuget (.NET) or yum/dnf (rpm).

Scenarios

1. A user is able to use the npm cli to publish js artifacts to Quay
2. A user is able to use the python3 client to publish python artifacts to Quay
3. A user is able to <some tool> to push LLM models and training data to Quay

Acceptance Criteria

• The feature is gated and clearly marked as Developer Preview
• A security assessment is performed and a review of authentication and authorization is completed
• Users are able to push and pull LLM models, Python artifacts, and JS artifacts

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. See syahmed@redhat.com

Open questions::

1. How should users push models and training data to Quay?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>