Author: t0xic0der (page 1 of 3)

Introducing MetaSource (or MDAPI 4)

We are excited to announce the general availability of the MetaSource (or MDAPI 4) in both the staging and production Fedora Infrastructure environments. The release includes an architectural rewrite of the MDAPI from Python to Go, making it a performant source of RPM repositories metadata as a REST service with 1:1 API compatibility. More details about the developments and acknowledgements are below.

Rewrite

The project faced a critical challenge due to its dependence on SQLite3-based RPM repositories metadata which were deprecated by the Fedora Linux 41 release. Rather than applying temporary workarounds on the existing codebase, we took this opportunity to fundamentally redesign the project. The improvements included optimized processing of XML-based RPM repositories metadata, swifter response towards HTTP REST operations, interactive documentation for ecosystem experience, stellar coverage across functional testcases among other things. The move from Python to Go programming language allowed us to take advantage of the performance benefits and resource efficiency – all while ensuring that the solution stays simple enough to maintain for a high-throughput HTTP service for a cloud-native first deployment.

Comparison

Sustained querying

ServicesSample
Count
Total
Duration
Per request
Duration
MDAPI
MDAPI v3.1.7
1000 requests63 minutes, 3 seconds3.7828 seconds
MetaSource
MDAPI v4.0.0
1000 requests42 minutes, 30 seconds2.5505 seconds
ServicesAverage
Memory
Minimum
Memory
Maximum
Memory
MDAPI
MDAPI v3.1.7
157.09 MiB
160,861 KiB
99.16 MiB
101,544 KiB
204.34 MiB
209,248 KiB
MetaSource
MDAPI v4.0.0
109.72 MiB
112,350 KiB
81.66 MiB
83,616 KiB
174.52 MiB
178,712 KiB

MetaSource (or MDAPI v4.0.0) performs roughly 33% faster than MDAPI v3.1.7 while using about 30% lesser memory than that on sustained querying operations. This means that MetaSource would be able to address approx 50% additional requests without furthering resource consumption. Please note that the results may vary depending on unknown variables like network bandwidth and querying nature.

Concurrent querying

ServicesSample
Duration
Total
Count
Per request
Duration
MDAPI
MDAPI v3.1.7
500 seconds148 requests7.3615 seconds
MetaSource
MDAPI v4.0.0
500 seconds310 requests3.5530 seconds
ServicesAverage
Memory
Minimum
Memory
Maximum
Memory
MDAPI
MDAPI v3.1.7
217.41 MiB
222,625 KiB
136.73 MiB
140,008 KiB
289.93 MiB
296,888 KiB
MetaSource
MDAPI v4.0.0
187.02 MiB
191,510 KiB
130.68 MiB
133,816 KiB
257.44 MiB
263,624 KiB

MetaSource (or MDAPI v4.0.0) performs roughly 52% faster than MDAPI v3.1.7 while using about 14% lesser memory than that on concurrent querying operations. This means that MetaSource would be able to address approx 110% additional requests without furthering resource consumption. Please note that the results may vary depending on unknown variables like network bandwidth and querying nature.

Appeal

This project would not have been possible without the help of Akashdeep Dhar, Kevin Fenzi, David Kirwan, Michal Konecny, James Antill, Steve Milner, Shounak Dey and countless others who have either contributed to Fedora Infrastructure projects ecosystem or the createrepo_c project. We ask the readers to contribute to the project by developing, maintaining, testing or documenting the project.

Introducing User Interface for Webhook To Fedora Messaging

As a part of our move from Fedmsg to Fedora Messaging in the last year, we announced the general availability of the Webhook To Fedora Messaging service. While the project was developed to replace the (now decommissioned) GitHub2Fedmsg service, we did not have a user interface for managing webhook binds with Fedora Messaging. The migrating users of the GitHub2Fedmsg service had to hence request for the creation of webhook binds via an issue tracker and the incoming users had to utilize the Swagger UI to create the webhook binds by themselves – which worked just fine but was definitely not ideal.

Given that since then, the project has evolved significantly into an ecosystem of Webhook-based communications to the Fedora Messaging. The support for Forgejo and GitLab repositories was added to support the Fedora Project’s and CentOS Project’s transitions to these platforms respectively. With active discussions around the frontend requests and design architectures, we finally came around to making an interactive user interface available for the Webhook To Fedora Messaging users. Please feel free to give it a try on the production environment and consider helping with the maintenance efforts of the project!

Fedora Council Elections: Interview with Akashdeep Dhar (t0xic0der)

This is a part of the Fedora Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Tuesday 20th May and closes promptly at 23:59:59 UTC on Monday, 2 June 2025.

Continue reading

Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der)

This is a part of the Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Tuesday 20th May and closes promptly at 23:59:59 UTC on Monday, 2 June 2025.

Continue reading

Announcing Webhook To Fedora Messaging

With the transition of the applications from Fedmsg to Fedora Messaging inching towards completion, today we want to introduce a new service, Webhook To Fedora Messaging. Webhook To Fedora Messaging has been researched and developed by the Fedora Infrastructure team members with the company of an Outreachy mentee over the last quarter to communicate with services using webhooks.

Webhook To Fedora Messaging takes webhook events from services and translates them into semantic messages to be sent over on the Fedora Messaging bus, to which every Fedora Project application can listen and act for automation. Currently, the project supports services like GitHub but going forward we plan on implementing support for services like Discourse, GitLab, Forgejo etc.

Continue reading

Fedora Council election: Interview with Akashdeep Dhar

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

Interview with Akashdeep Dhar

Continue reading

CPE Weekly update – Week 33 2023

This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat.

We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 14 August – 18 August 2023

Continue reading

CPE Weekly update – Week 24 2023

This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on the #redhat-cpe channel on libera.chat.

We provide you with both infographics and text versions of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details look at the infographic.

Continue reading

Wrapping up the Fedora Websites and Apps Community Initiative: Part IV

This is the fourth post in a series covering details about the journey of the Fedora Websites and Apps community Initiative, those who were involved in making it a grand success, and what lies ahead down the road for the team. If you have not already, read the previous post before delving into this one.

Promising community diversification

By October 2022, the experiment of me stepping away to assess the team’s strength began to show promising results. Niko Dunk, Jefferson Oliviera, Deepesh Nair, and many others, joined the development efforts. Likewise, Madeline Peck, Jess Chitas, Dawn Desmarais, and numerous others contributed to the design aspects. Hari Rana also participated in testing, alongside others who were already involved. I am immensely grateful to Ashlyn Knox, Francois Andrieu, and Niko Dunk for their effective collaboration with members from Fedora Infrastructure, Fedora Design, Fedora Marketing, and other teams. Together, they gathered requirements and provided valuable feedback. This development initiative commenced on GitLab itself, making it the first project to be entirely developed there. The team utilized planning tools such as epics, stories, issues, and timelines. In addition to Fedora Websites 3.0, we began collecting testimonials to gauge community interest in maintaining Fedora Badges.

Continue reading

Wrapping up the Fedora Websites and Apps Community Initiative: Part III

This is the third post in a series covering details about the journey of the Fedora Websites and Apps community Initiative, those who were involved in making it a grand success, and what lies ahead down the road for the team. If you have not already, read the previous post before delving into this one.

Processes and Visibility

Around April 2022, I shifted my focus to rewriting our team documentation. I aimed to maintain high codebase standards for our websites and applications while ensuring a clear understanding of our team processes. This would ensure that the team’s work could continue even after completing the community initiative. We actively participated in community events such as Fedora Linux Release Parties and Nest With Fedora, where we shared updates on our projects and discussed special team initiatives. Ashlyn Knox and Onuralp Sezer went the extra mile by organizing interactive workshops during these events, both personally and on behalf of the team. Their efforts aimed to onboard new members and educate the community about the latest developments in web technologies. Meanwhile, Ojong Enow and Subhangi Choudhary diligently pushed forward with their assignments as we neared the completion of our cohort.

Continue reading
Olderposts

Copyright © 2025 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑