Hi Everyone,

This is an email to bring everyone up to speed with the Fedora Messaging Notifications (FMN) Replacement initiative.

What is FMN?
FMN is a service which allows users to create filters on messages sent via the message bus in Fedora Infrastructure. Users can then forward these notifications to their respective email addresses and/or IRC profiles.

Why is it being replaced?

• 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
• 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.

Design Plan

Write a fedora-messaging consumer that would triage incoming messages and add notifications to one queue per destination (email, irc, matrix). They would be on a FMN-specific vhost on the RabbitMQ server. Then write AMQP consumers for these queues to actually send the notifications. This would allow the IRC and Matrix notifiers to maintain a permanent connection to the IRC/Matrix server(s).

This work requires all applications to use Fedora Messaging Message Schemas, because the triage component will rely on schemas to extract information from the messages.

Prospective Timelines

First Month

• The development team has been onboarded
• The backlog has epic level tickets created
• Testing criteria is loosely defined for performance, i.e. what is the min/max acceptable time for receiving a notification

Three Months

• An update is sent to the lists on work underway
• Infra leads have been invited to a review of the work to date
• A firmer timeline for project delivery has been defined
• There is testing criteria/benchmarking agreed to

Six Months

• The service is deployed in staging or its in production but it is not enabled for everyone yet
• Testers are invited to onboard into the new service and help test performance
• An outage period for cutover to the new service has been identified and planned if needed

Nine Months

• Hotfixes are applied

Team Members

Aurelien Bompard - Tech Lead Frontend & Message Consumer
Nils Philippsen - Tech Lead Web API Backend
Ryan Lerch - Developer & Frontend Designer
James Richardson - Developer & Agile Practitioner

If there are any questions/concerns/advice/opinions/etc please don’t hesitate to get in touch with us.

Regards,

James

--