From Fedora Project Wiki

Revision as of 20:31, 29 October 2009 by Mdomsch (talk | contribs) (add mirroring use cases)


Create a Messaging infrastructure within the Fedora Project to facilitate communication, interaction, and integration between services within the Fedora Infrastructure.



We're currently in the planning stage of the SIG. Bringing interested people together to flesh out the who, what, where, when, and how.


  • #fedora-admin and #fedora-devel on Freenode IRC
  • Slides from a talk given at Linux Fest Northwest 2009 by Jesse Keating


None yet, need to work out a timeline for implementing a Messaging system.


Things to add to schedule in order to implement this

  • setup a qpid server in publictest infrastructure
  • Figure out how QMF fits into our plans
  • Design notification server to interact with the bus, receiving messages and sending notifications out
    • lmacken mentioned that a moksha plugin might be suitable for this
    • Figure out how people can change their notification settings -- should the settings be in the apps and then the notification server polls the apps for updates? Or should the apps redirect people to the notification server?
  • setup notification server on publictest infrastructure
  • migrate qpid and notification server to stg.
  • deploy
  • port apps to use notification server
    • koji plugin
    • pkgdb change
    • fas? (Or is this essential enough that it should stay in fas?)
    • bodhi
    • cvs commit mail



  • Bring people into the SIG
  • Discuss high level goals of the SIG
  • Create a schedule
  • Define an object & event messaging model
  •  ???
  • Profit

Use Cases

Triggered Mirroring

  1. Message when the NetApps snapmirror goes out of sync, due to a write to the master. Tier 1 mirrors subscribe, and don't pull until next message.
  2. Message when the NetApps snapmirror is back in sync. Tier 1 mirrors subscribe, and should pull now.
  3. Message when each Tier 1 mirror has started syncing. Tier 2 mirrors subscribe, and don't pull until the next message.
  4. Message when each Tier 1 mirror has finished syncing. Tier 2 mirrors subscribe, and should pull from their Tier 1 mirror now.

In all cases, having a clue as to which part of the tree has just changed would be useful. Even a 'directories from this point downward are likely to have changed' would be of benefit.


Links to documentation and project pages for the various tools we'll be using.