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?
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
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.
- 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.
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).
work requires all applications to use Fedora Messaging Message Schemas,
because the triage component will rely on schemas to extract
information from the messages.
- 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
- 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
- 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
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.