It’s been two months since we announced the kick-off of the Fedora Messaging Notification (FMN) Replacement initiative. Here’s the update on our progress since then.
We highlighted the reasons why we’re replacing the old (FMN) service in the kickoff email. As a refresher, here are the issues it faces.
- Message Delivery Lag. In times of peak congestion on the message queue (e.g. during a mass rebuild) it can take days for messages to be delivered to users
- Deprecated Library. The current version of FMN uses the deprecated fedmsg library to connect to our legacy, ZeroMQ-based message bus, instead of connecting to the new message bus which is based on AMQP. While messages are bridged between both systems, we eventually want everything to run natively on the new bus so we can decommission the old one.
- UI/UX. From ad hoc discussions with the development community we learned that one of the major issues with FMN is its user interface. The workflow for creating new filters is complicated and confusing, and users have to define filters separately for different destinations (i.e. email and IRC). This is due to how the database is designed.
What have we done so far?
As it stands right now, most of the basic framework and code is in place.
Ryan Lerch has been working tirelessly to improve the UI/UX which is a massive drawback of the prior version. Aurélien Bompard, our tech lead, has done an amazing job of implementing the features that users will need with this service, mostly focusing on the front end. Nils Philippsen, our back end tech lead, focused initially on designing the database and back end API.
We had a planning call with Aoife Moloney, the project’s product owner, and the team is focusing on deploying the code to staging by the end of November. With that in mind, there are some very important tickets on our tracker board that we’ll be focusing on for the next couple of weeks to get us there.
What we’re focusing on
The first priority is to complete the task of sending notifications to a user’s email. We need to test the consumer consuming a message, reviewing the rules, then sending the message. One we get that working end-to-end, IRC and Matrix will follow respectively. Next is to develop the Ansible role to deploy the code to the staging environment. We want to deploy to staging first so that we don’t hammer any existing services. Along with that, we will need to generate a list of services that FMN will interact with, i.e. dist git, FASJSON, Ipsilon, and more. And of course, testing everything.
So dear reader, that’s the story for now. Be sure to come back in December for the next exciting chapter of FMN Replacement!