Explore idea of a notification server #151

New issue

Closed

opened 2007-09-13 22:34:57 +00:00 by toshio · 7 comments

toshio commented

2007-09-13 22:34:57 +00:00

{{{
#!rst

Pre-planning

Would a notification server add value to our architecture?
Does it simplify our other apps?
Would integrating it into our apps be intrusive or easy?
How to balance generality with specifics of our environment?

Use case

User makes several changes in packagedb interface
Packagedb makes change and constructs event messages of [who did it, type of event, message]
Packagedb adds event messages to a queue messages are sent to the notification server
Notification server receives message. Saves to its queue. Sends acknowledgement.
Packagedb receives ack and removes message from queue.
After timeout, notification server processes queue, constructing messages, saving logs, and updating RSS feeds.
}}}

{{{ #!rst Pre-planning ============ * Would a notification server add value to our architecture? * Does it simplify our other apps? * Would integrating it into our apps be intrusive or easy? * How to balance generality with specifics of our environment? Use case ======== 1. User makes several changes in packagedb interface 2. Packagedb makes change and constructs event messages of [who did it, type of event, message] 3. Packagedb adds event messages to a queue messages are sent to the notification server 4. Notification server receives message. Saves to its queue. Sends acknowledgement. 5. Packagedb receives ack and removes message from queue. 6. After timeout, notification server processes queue, constructing messages, saving logs, and updating RSS feeds. }}}

toshio commented

2009-02-06 22:52:43 +00:00

Author

Talked to lmacken the other day and we think we might be able to do this using moksha's infrastructure. We'd pass messages using AMQP and moksha would take care of disbursing the information via email, RSS, etc.

toshio commented

2009-02-06 22:54:18 +00:00

Author

to see if we could handle that information as well. We'd need to be careful about security to do that, though.

See also: https://fedorahosted.org/fedora-infrastructure/ticket/675 to see if we could handle that information as well. We'd need to be careful about security to do that, though.

lmacken commented

2009-03-18 20:44:59 +00:00

I think that setting up a Qpid AMQP broker would be a great start. From there, we can easily start sending various infrastructure events to it. Then, hooking up Moksha to it is going to be trivial, and will allow us to easily write "consumers" of these messages that can do interesting things, such as send email notifications, perform various jobs, etc.

toshio commented

2009-10-05 21:08:13 +00:00

Author

Seems like qpidd setup is the first step in this.

mmcgrath commented

2009-10-05 21:23:49 +00:00

This is actually 'up'ish now. The big part was me training myself on how it works. If we have test messages let me know because I can set it all up in staging fairly quickly.

kevin commented

2012-03-09 03:56:51 +00:00

Owner

Adding ralph here, as he is going to be working on this now.

We are looking at going with a 0mq setup.

Targeting for by Fedora 18, please adjust as you like.

Adding ralph here, as he is going to be working on this now. We are looking at going with a 0mq setup. Targeting for by Fedora 18, please adjust as you like.