<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> # :railway_track: RPM MVC Implementation plan Please see https://gitlab.com/gitlab-org/gitlab/-/issues/296785 for the initial investigation and [summary](https://gitlab.com/gitlab-org/gitlab/-/issues/296785#note_1070086773) that led to this plan. To support RPM packages, we need to do a few things: 1. Create an API to accept and deliver RPM packages through an API endpoint 2. Read the uploaded files and extract metadata from them 3. Create and maintain set of metadata xml files that make up the repository using the extracted package metadata (1.) is straight forward and will match much of what we do for other package formats. (2.) contains the most unknowns at this time. (3.) is the most tedious task as it involves building a custom set of xml parsers and generators. We use the [nokogiri](https://nokogiri.org/) gem for this. ## :label: Issues :warning: This is a work in progress and is being used as a space to plan out the issues and ordering. As issues are created, they will be added to this epic with more complete details. The ordering and contents of this section may change. :warning: ### API 1. [Skeleton API](https://gitlab.com/gitlab-org/gitlab/-/issues/370867) 2. [Workhorse acceleration interception for the upload route](https://gitlab.com/gitlab-org/gitlab/-/issues/370869) 3. [Authentication/Authorization](https://gitlab.com/gitlab-org/gitlab/-/issues/370868) ### Package and repository creation 1. [RPM package creation - when a package is uploaded, parse the name to find or create an existing package.](https://gitlab.com/gitlab-org/gitlab/-/issues/371802) 2. [Add event tracking for uploads and downloads](https://gitlab.com/gitlab-org/gitlab/-/issues/371808) ### RPM Parsing 1. [Create `packages_rpm_metadata` and/or `packages_package_files_rpm_metadata` table to store metadata for the package and/or files.](https://gitlab.com/gitlab-org/gitlab/-/issues/371798) 1. [RPM process upload worker](https://gitlab.com/gitlab-org/gitlab/-/issues/372737). This worker uses the various extraction services and updates the repository metadata after a file is uploaded. 4. Have a parser to handle each of the three RPM file types. 1. [`.rpm` extraction service](https://gitlab.com/gitlab-org/gitlab/-/issues/372648) 1. [`.src.rpm` extraction service](https://gitlab.com/gitlab-org/gitlab/-/issues/372649) 1. [`.drpm` extraction service](https://gitlab.com/gitlab-org/gitlab/-/issues/372650) ### Repository metadata files 1. [Create `project_package_files` and a new uploader to manage project-level package registry files.](https://gitlab.com/gitlab-org/gitlab/-/issues/372286) 1. [Generate empty metadata files on the first RPM upload to a repository](https://gitlab.com/gitlab-org/gitlab/-/issues/371800) 1. RPM repository update worker that runs anytime a new package completes its metadata extraction or anytime a package is deleted to update the various metadata files. 4. RPM repository update service - starts the process of taking a new file or set of extracted metadata and then spawning additional workers/services to update each of the various metadata files. A base service/generator may be useful. 1. [`filelists` updater service](https://gitlab.com/gitlab-org/gitlab/-/issues/372652) 2. [`primary` updater service](https://gitlab.com/gitlab-org/gitlab/-/issues/372733) 3. [`other` updater service](https://gitlab.com/gitlab-org/gitlab/-/issues/372735) ### GraphQL support (to unblock frontend) 1. Package metadata GraphQL types ### Frontend work 1. Display RPM-specific metadata 2. RPM help snippets (configure remote and install) 3. Display RPM repository files (needs input from ~UX) ### End to end testing 1. Add e2e testing for RPM packages ([package e2e testing reference](https://about.gitlab.com/handbook/engineering/development/ops/package/quality/)). ### Documentation 1. User documentation - describe how users can authenticate and use the registry ([Example of similar doc for PyPI](https://docs.gitlab.com/ee/user/packages/pypi_repository/index.html)) 2. API documentation - document the individual API endpoints. ([Example of similar doc for PyPI](https://docs.gitlab.com/ee/api/packages/pypi.html)) 3. Development documentation - document RPM-specific processes/conventions/domain knowledge. Much of this may come from the investigation issue or may be in the form of sequence/system diagrams. ([Example of similar doc for Debian](https://docs.gitlab.com/ee/development/packages/debian_repository.html))