Ticket #151 (closed task: fixed)

Opened 7 years ago

Last modified 21 months ago

Explore idea of a notification server

Reported by: toshio Owned by: ralph
Priority: trivial Milestone: Fedora 18
Component: Development Version:
Severity: Normal Keywords:
Cc: J5, lmacken, alexlan, mmcgrath, ralph Blocked By:
Blocking: Sensitive:

Description

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.

Change History

comment:1 Changed 6 years ago by toshio

  • Cc J5 added

comment:2 Changed 6 years ago by lmacken

  • Cc lmacken added

comment:3 Changed 6 years ago by alexlan

  • Cc alexlan added

comment:4 Changed 5 years ago by toshio

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.

comment:5 Changed 5 years ago by toshio

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.

comment:6 Changed 5 years ago by lmacken

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.

comment:7 Changed 5 years ago by toshio

  • Cc mmcgrath added

Seems like qpidd setup is the first step in this.

comment:8 Changed 5 years ago by mmcgrath

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.

comment:9 Changed 2 years ago by kevin

  • Owner changed from toshio to ralph
  • Milestone set to Fedora 18
  • Cc ralph added

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.

comment:10 Changed 21 months ago by ralph

  • Status changed from new to closed
  • Resolution set to fixed

0mq setup is along and moving. See #fedora-fedmsg and http://fedmsg.readthedocs.org/en/latest/status.html

Going to close this one :)

Note: See TracTickets for help on using tickets.