On Wed, 2020-02-26 at 08:26 +0100, Clement Verna wrote: > Hi all, > > FMN (https://apps.fedoraproject.org/notifications) is currently one > of the main blocking point for dropping fedmsg in favour of fedora- > messaging. > FMN is quite important to the community and the composition of Fedora > because it gives emails and notifications on commits, composes, > builds and updates via email and other tools. > > However, the code base is written in Python 2.7 and not maintained > anymore. Currently the service has to run on a Fedora 28 system to > continue running. This causes multiple problems and concerns, and > needs to be addressed before the datacenter move in June. > > In order to start putting together a specification for a replacement, > we should try to look at the minimum requirements for a notification > system. For example the current system supports sending notifications > to IRC, emails and SSE (Server Sent Event), Can we live without SSE ? > Can we live without IRC ? Do we need it to monitor everything it does > currently or just a subset of items that the community has found > useful. > > Let's use this thread to brainstorm ideas on what we need. > FYI before I left the team I started hacking up a replacement[0]. My design focused on how to get as rich a feature set as I could using only AMQPs currently available filtering features. There's a couple feature differences for end-users: * Users can filter on message importance based on fedora_messaging_severity and any documented optional header[1]. Users can also provide AMQP-formatted topics they'd like to receive notifications for (again, with a severity filter). There's no running arbitrary regex over messages to filter. * Batch delivery is only available at fixed intervals, unlike the current system which takes how many pending messages there are as well. This puts all the responsibility of filtering the messages for each user on RabbitMQ (which is very good at filtering messages and keeping them until a user wants them). Each user gets a message queue in the broker, and all the notification service needs to do is make sure the bindings are set up to filter messages into the queue and dequeue + deliver the message. The prototype is using Twisted for that. There's a non-trivial amount of work to do on the prototype, and I never did anything for a web UI, but it's a skeleton of what I'd recommend as it minimizes the amount of work you have to do. If you wanted to be even more minimal, you could see about using RabbitMQ plugins to handle sending the emails and IRC notifications. I believe there's already one for email available, but you might have to write a little Elixer or Erlang for IRC notifications. If you wanted to get even more minimal, you might be able to expose the RabbitMQ web UI and just create users for each FAS account with permissions to create their queues (and no other queues) themselves, but that would be quite a bit less usable. [0] https://github.com/jeremycline/fedora-notifications [1] https://fedora-messaging.readthedocs.io/en/stable/wire-format.html#optional _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
