From Fedora Project Wiki

Revision as of 23:21, 24 September 2012 by Ralph (talk | contribs)


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



We have been in a planning stage of the SIG for many years: bringing interested people together to flesh out the who, what, where, when, and how.

We started earnest development in Spring of 2012 around fedmsg. See this table for integration status.



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
  • What should the API look like?



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

Use Cases

At FUDcon Toronto 2009 we came up with this list of needs for each of the services that may end up on the bus, also noted is what services would then be sending that data out on the bus.

Amqp cases.png

For this the following wedges would need to be made to place the services on the bus:


  • NetApp
  • Compose
  • AutoQA
  • PkgDB
  • Koji
  • Bodi
  • SCM
  • Bugzilla
  • Zabbix

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.

Naming Scheme

We need to define what this will look like, perhaps something like:

  • org.fedoraproject.*
  • org.fedoraproject.fas


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