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.
Thanks all
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.
I'd note that a key feature of FMN is that it provides human-readable summaries of messages. For fedmsg this is achieved through the fedmsg metadata system, and the Fedora providers for it:
https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/
for fedora-messaging, the intended way to do approximately the same thing is with message schemas:
https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema
as part of modernizing FMN and rewriting it on fedora-messaging, we might well need to get fedora-messaging schema coverage up to a similar level as we have fedmsg meta coverage. We may want to see if we can come up with an automated or semi-automated process for converting fedmsg meta providers to fedora-messaging schemas, even...
On Wed, 26 Feb 2020 at 09:17, Adam Williamson adamwill@fedoraproject.org wrote:
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.
I'd note that a key feature of FMN is that it provides human-readable summaries of messages. For fedmsg this is achieved through the fedmsg metadata system, and the Fedora providers for it:
https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/
for fedora-messaging, the intended way to do approximately the same thing is with message schemas:
https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema
as part of modernizing FMN and rewriting it on fedora-messaging, we might well need to get fedora-messaging schema coverage up to a similar level as we have fedmsg meta coverage. We may want to see if we can come up with an automated or semi-automated process for converting fedmsg meta providers to fedora-messaging schemas, even...
Yes this also part of this thread to identify which messages we really care about, so that we can focus on providing schema for these first. Messages that are a little bit less important would come later.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Few things from my head: * Support for simply adding new messaging scheme, so there is no need to rewrite the application each time something new wants to be added. * Subscriptions to topic with filters, this will be probably limited by provided scheme. * Web interface for users (could be something similar to what we have right now), where they could subscribe, unsubscribe from topics.
About the communication channels, for me e-mails are enough, but it will be good to provide a way to add new channel if needed.
Michal
On 26/02/2020 08:26, 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.
Thanks all
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org 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@lists.fedorapro...
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
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.
kevin
On Wed, 26 Feb 2020 at 15:58, Kevin Fenzi kevin@scrye.com 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.
infrastructure@lists.fedoraproject.org
-
Adam Williamson -
Clement Verna -
Jeremy Cline -
Kevin Fenzi -
Michal Konecny -
Stephen John Smoogen