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.
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.
- 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
- An outage period for cutover to the new service has been identified
and planned if needed
- Hotfixes are applied
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.
Associate Software Engineer
He | Him | His
Red Hat Waterford <https://www.redhat.com/>
Cork Road, Waterford City
M: +353851970521 <+353877545162> IRC(preferred): jrichardson