Designing An Alternative Replacement

As Pagure Dist Git is a comprehensive service that is used by over ten other infrastructure services - it is important to ensure that the replacement for it does not break compatibility with them. The applications dependent on Pagure Dist Git mostly depend on its Git API, its HTTP API, its Lookaside Cache, hosted HTTP resources as well as the messages sent to the Fedora Messaging hub. Ensuring that these stream of information remain consistent throughout the transition to the newer replacement.

It is also crucial to ensure that the solution is designed to be as agnostic as possible in terms of the Git forge solution. This helps us avoid possible decision biases that may arise as a consequence of a certain feature being available or absent on a certain Git Forge solution. As Pagure Dist Git provides a unique application around the good old Git workflow, availability or absence of certain desired features similar to those from the existing production deployment must be taken as a coincidence.

Interaction diagram

The following illustration explains how the Pagure Dist Git alternative would work alongside other infrastructure applications and services. The replacement would be a system chiefly consisting of three elements - Messages Handler, Dist Git Service and Compatibility Metaservice.

Messages Handler


This element is responsible for sending appropriately titled messages to the Fedora Messaging bus by listening into events taking place in the Dist Git Service deployment. It is important to ensure that the schema either more or less the same or the changes to the schema are propagated across various projects dependent on the messages emitted by the Dist Git Service to ensure maximum compatibility. Some example of such projects are Fedora Notifications, COPR, Fedora CI, Bodhi and Datanommer.

It is strongly recommended to pick a Git Forge solution that supports webhooks-based event execution as this can significantly help save efforts on writing polling conditions that lead to send of messages from the Dist Git service to the Fedora Messaging bus. As such one of the previously suggested projects i.e. Webhook To Fedora Messaging can prove to be extremely useful here when implemented as then, this element would be reduced to being only a special configuration of the said project.

Dist Git Service


This element is primarily responsible for storing repository resources using Git (for RPM specfiles and codebase assets) and Git LFS (for large-sized binaries and source tarballs) as well as for providing means to interact with the said resources using an interactive API accessible both via HTTPS and SSH. An internet frontend is also necessary for use-cases like managing inter and intra repository collaboration, showing package statistics and information from various other relevant services etc.

It is strongly recommended to the pick a Git Forge solution that allows for granular access control management in terms of both users and groups associated with a repository. Having the access control of the said solution play well with the Fedora Project’s existing AAA stack is crucial to ensure that the group accesses can be governed from Fedora Account System groups using SAML. Also, having an HTTP API that allows for customizing its capabilities to match those of Pagure Dist Git is necessary.

Compatibility Metaservice


The services that depend on Pagure Dist Git and are maintained by the team can easily have changes introduced to them to match the compatibility of the changed Dist Git Service platform. The process can be slower for the projects that depend on Pagure Dist Git and are not maintained by the team and hence it is important to maintain an equivalent amount of compatibility while the changes are introduced in the subsequent release by supporting the same API calls while setting a obsolescence timeline.

The metaservice is expected to mimic the existing Pagure Dist Git API to help applications and services like Fedpkg, COPR, Fedora CI, Bodhi and Packit obtain the same results as they would when the older API would have been used. This is done by hosting the metaservice in the same location as the Pagure Dist Git API and letting it receive the requests from the clients. These requests are then translated to work accordingly with the newer API schema to receive responses which are again translated to the older schema.