RFC: Flatpak support in Katello

Development RFCs
, , , ,
1

RFC: OCI-Spec Flatpak Support in Katello

Hi community. Katello is in the process of introducing support for oci-spec flatpak repositories. We have had some design discussions internally within katello and pulp with feedback from the flatpak team. Below is the proposal we have come up with to enable this support in Katello.

Current State

Katello’s content backend, Pulp, already supports OCI-based Flatpak repositories via the pulp-container plugin. These repositories can be synced as container repositories in Katello. Pulp also functions as a Flatpak registry, serving all synchronized Flatpak repositories through a Flatpak registry index.

Design Proposal: Introducing OCI-Spec Flatpak Support in Katello

Goal 1: Importing Flatpak Repositories

To support OCI-spec Flatpak repositories, Katello will introduce a new model: Flatpak Remote. Two Flatpak remotes (Red Hat and Fedora) will be pre-configured and automatically created. Users will also have the ability to add custom Flatpak remotes, supporting the following registry specification: Flatpak OCI Registry Spec.

Pre-configured Remotes:

The content for these remotes is hosted at https://registry.redhat.io/ and https://registry.fedoraproject.org/, either read from the Flatpak index or pre-configured in Katello.

Authentication:

Syncing repositories from the Red Hat registry will require authentication. Katello will support setting up authentication per remote.

Remote Introspection:

Katello will simplify the importing process by introducing Remote Introspection. Instead of manually creating individual container repositories, introspection will scan the remote’s Flatpak index, pre-configure repositories for import, and save these as Flatpak Remote Repositories in the Katello database. This pre-configuration means that introspection will only need to be run once per remote to start creating the flatpak repositroies in Katello. The introspection will need to be re-run to pull down updates on the remote index.

Benefits:

  1. Simplifies Flatpak repository creation as users might not know the registry and repository name to point to for Flatpaks.
  2. Enables Katello to maintain dependency information prior to syncing, parsed from the Flatpak index and possibly inform the user of the same at the time of repository creation. (Dependencies - Flatpak documentation)
  3. Allows us to identify Flatpak repositories easily and add Flatpak-specific features to these container repositories.

These Flatpak Remote Repositories could be globally scoped to support reuse, while Katello repositories created from these remotes will be scoped to taxonomy and product as usual. These repositories can be synced as any other container repository once created.

Goal 2: Managing the Lifecycle of Flatpak Repositories

Flatpak repositories will be limited to images tagged as latest, with no option to modify this setting. Repositories created via the proposed workflow will be treated as container repositories within Katello, but with the following differences:

  • The include-tag will always be set to latest.
  • We could introduce runtime dependency solving for Flatpak applications.

Goal 3: Access management and distributing Flatpak Content to Clients

Clients will use the Flatpak CLI to consume repositories managed by Katello. The Flatpak CLI expects a Flatpak index at the remote endpoint, which Pulp currently serves as an OCI-spec compliant Flatpak index. However, Pulp’s Flatpak index contains all repositories, including those in different content views and environments.

Katello Flatpak Registry:

To enable access control, Katello will act as a proxy between clients and the Pulp Flatpak index. Client requests will be forwarded to Pulp, Katello will intercept the response and filter the repository list based on client access rights and return only the relevant repositories. This introduces some level of complexity in our design but is necessary for access control.

Smart Proxy Integration:

Smart proxies will also need to filter the Pulp index served by proxy pulp, similar to how the existing container gateway plugin operates. This will ensure that only authorized repositories are served to clients registered to a proxy.

Goal 4: Client Setup

Clients using the Flatpak CLI will need to add a remote that points to the Katello Flatpak proxy. An example configuration might look like:

flatpak --user remote-add --authenticator-name=org.flatpak.Authenticator.Oci katello oci+https://centos9-katello-devel.example.com/

Flatpak expects the index to be served at /index/static, which Katello will introduce. Today, Pulp serves the index at /pulpcore_registry/, but this is currently disabled in Katello by a Pulp setting.

Automated Setup:

This client setup can be automated during the Global Registration process, or alternatively, files can be created remotely on the client to configure the remote. Additionally, the client will need podman login credentials for the Katello/Pulp container registry to download Flatpak images via the flatpak install command.

Limitations/Concerns:

  1. The initial implementation will not enable support for ostree flatpaks which means flathub.org support will not be available. This is primarily because katello doesn’t enable pulp-ostree plugin responsible for managing ostree content.

  2. Because of the way Katello manages lifecycles, the pulp flatpak index can get pretty large for users with multiple CVs with these flatpak repos with large numbers of versions. Each of these version repositories in Katello is a unique one as far as pulp is concerned. This would mean the Katello registry proxy would be parsing through very large json for every request to filter out authorized repositories.

Thank you for reading through the proposal and please let me know your thoughts on this and reach out if you have any questions and/or suggestions.

5 Likes