Infrastructure/Projects

Infrastructure Projects

This page lists all the "larger" infrastructure projects that would benefit the community. Anybody in the community can announce that they are interested, contact the person listed as a point of contact or post in the infrastructure discussion topic, and get started!

The projects are listed in chronological order of "somebody coming up with the idea".

If you want to discuss this page itself or suggest new projects, you can do so on this discussion thread.

ARA

Added on 2024-02-05. Contact: User:Abompard, User:Zlopez

Install and configure ARA in OpenShift with its hook in our ansible repo.

This is redundant with our longer-term project of moving to AWX, but doing so would require us to heavily reorganize our Ansible repo and we don't know when we'll be able to do that, while ARA could be used right now. If you think ARA is cool and you want to deploy it in Fedora, go ahead!

Keycloak prototype

Added on 2024-02-05. Contact: User:Abompard

IPA-tuura is an integration layer between Keycloak and FreeIPA. It's very promising and under active development, and could provide us with an alternative to Ipsilon. IPA-tuura is usable right now, and only lacks Kerberos authentication forwarding. It's based on an open specification, SCIMv2, and is written in Python (Django).

The plan would be:

• Deploy and configure Keycloak and IPA-tuura in staging OpenShift and configure them with our IPA servers.
• Import OAuth2 configuration from Ipsilon
• Configure the mapping of IPA attributes to OIDC attributes in IPA-tuura
• Test with test-auth, the basic authentication testing app
• Check how the mapping of AWS groups could be done in IPA-tuura
• Follow the implementation of Kerberos auth in IPA-tuura

Poddlers

Added on 2024-02-05. Contact: User:Abompard

The problem with the current Toddlers implementation:

• a message that crashes a toddler prevents it from getting processed by all the toddlers that come after it
• if one toddler consumes a lot, other toddler pods can be added but they multiply all the toddlers, not only the one that needs scaling
• it conceptually re-implements a queue system, except it’s in a for loop:
  • messages are stored in memory during processing
  • topic matching is done in Python

The plan would be to convert toddlers to Fedora Messaging consumers so that a crashing toddler does not block the others.

• Each consumer will be a pod in a single Openshift project
• The pod can have as many replica as needed
• Each consumer will have separate queues and only be subscribed to what they actually need.
• The code can remain in a single toddlers repo, the toddler being run will be chosen by the APP_SCRIPT environment variable that s2i uses and is defined in the deploymentconfig.yaml file.
• Special attention should be given to avoid duplication in the deploymentconfig.yaml configuration file.

Badges

Added on 2024-02-06. Contact: User:Abompard

It’s unrealistic to hope that the badges rewrite will be ready before RHEL7 goes EOL. We’ll have to do with the current implementation (see its description) for a while.

Tarhir

• Make it use OIDC, like Bodhi
• Port to Fedora Messaging (should be simple, see tahrir/tahrir/notifications.py)
• Refresh Pyramid (must work on EL9)

fedbadges

• Port the consumer to Fedora Messaging

MirrorManager

User:Abompard is currently working on this. Discussion thread.

• Rework the scripts
• Deploy to Openshift
• Sanitize the codebase
• Maybe make it usable by other distributions??

Easyfixes

Added on 2024-02-06. Contact: User:Abompard

The latest hack is currently a static page built in OpenShift by a cron job every hour. It's a hack of a hack and should be properly rewritten. This project could be the subject of an internship.

• Use an actual database instead of parsing a wiki page
• Use authentication
• Every authenticated user can define dashboard pages that would gather multiple tags. For example, the "easyfixes" dashboard would collect "easyfix", "good first issues", etc, the "CPE" dashboard would collect the "cpe" tag, the "Larger projects" dashboard would collect "next phase", "long term", etc.
• Dashboards can be owned (editable) by users or groups and readable by users, groups or public
• Public dashboards can be viewed without authentication, accessible from the front page
• To build a dahsboard, the user can list a project on Github / Gitlab / Pagure
• Each issue will have informative details such as the description, the creation date, the last modification date, whether it's assigned to someone, other tags, etc.
• Backend the crawler runs asynchronously from a cron job.
• The backend is modular and supports Github, Gitlab, and Pagure. It should be easy to add Codeberg one day, for example.

Strech goals:

• The crawler can accept webhooks from the forges, detect if a tag has been applied to an issue, and refresh the corresponding entries in the database. Adding a project to track would display the URL (and secret?) to add to the project's webhooks.
• Users can authenticate with Github / Gitlab / Pagure's oAuth2/OIDC systems, which would give them the token to automatically add the webhook to the project if they have the proper rights
• The frontend is dynamic (Vue.js preferred for coherence with other apps) and will refresh dashboard pages when the data is updated by the crawler.

Webhook to Fedora Messaging gateway

Added on 2024-02-06. Contact: User:Abompard

We currently have multiple applications that receive a webhook from an online app and turn the content into a Fedora Messaging message. Some of them are very old and are still using fedmsg, others are kinda recent and more maintainable (with tests, CI, etc).

It would simplify our setup and our maintenance to regroup all that in a single app with multiple endpoints. There's been an investigation on this subject already.

Git forge

Added on 2024-02-07. Contact: User:Humaton

Fedora project is currently using Pagure as its base for git repositories as well as for DistGit implementation. While Pagure is getting some traction now, there are other healthy open-source implementations of a git forge.

Make kerneltest run in OpenShift

Added on 2024-02-16. Contact: User:Abompard

The KernelTest app (deployed here needs to be S2I-enabled to run in Openshift. This is a rather simple task and would be a good fit for someone who wants to learn about how apps are deployed in Openshift.

It should also be made to use sqlalchemy-helpers and flask-oidc to reduce duplicated code.