On Wed, 26 Feb 2020 at 15:58, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Wed, Feb 26, 2020 at 08:26:09AM +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.
First I can add a bit of history/background for everyone here:
Long ago every app in fedora infrastructure (koji, bodhi, etc)
implemented it's own notification system (usually via email). So, in
order to change things a user would have to go to each system, find
prefs, find how it's ui was implemented and try and adjust things.
Additionally, this was a massive duplication of effort, with every app
implementing these same things over and over differently.
As soon as fedmsg bus came along, we were able to turn off the old apps
notification systems (except for bodhi, which I think still emails
itself) and have a app that sits and listens for fedmsgs and notifies
users. This is a win for users in that there's one place to go to change
things and a win for developers because they don't need to implement a
notification system at all, just make sure they emit messages for
everything that is of interest in their app.
Personally, I think both email and IRC are part of a minimal
replacement. I think SSE was for the planned android app, which we never
really deployed.
The current FMN app is SUPER flexable, which is awsome, but also makes
it really confusing for people. I think a more simple interface that
lets you choose topics you want to get notified about would do.
I think it's vital to have several 'predefined' profiles:
* packager - if you are in the packager group, get all your packages
commits, etc.
* sysadmin - you want to know about nagios alerts, ansible playbook
runs, etc.
* releng - you get signing, compose info, etc.
* qa - updates pushes info? openqa results? rc composes?
* Possibly some more defaults for other groups?
I think the current FMN batching options are too much. Just say 'daily
digest' 'as they happen' or some small subset.
I don't think we need to allow validating and using arbitrary email
addresses in the first cut, just use the fas account one.
Probibly we should make a wiki page and collect everything and then
order importance and see what we NEED to have in a first replacement.
If we have email, I would like to request that the tool tracks bounces and puts people who have a large bounce rate on hold. I have to at least once every couple of months go onto bastion and clean out a large queue of emails which are never going to be delivered but we try to do day after day. There are 3 problems with us trying to continue delivering mail to nonexistant accounts:
a) When there is a storm of activity, legitimate deliveries can get behind
b) we every now and then have postfix run out of room
c) various spam tools check to see if you keep delivering things and then score you higher as a possible spammer. Our biggest clients of gmail do this regularly where they will start putting our other deliveries at a later time and once I clean out the 10k never going to deliver ones.. they start allowing deliveries.
Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
