From Fedora Project Wiki


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 and this diagram for the system-wide view.



The rough outline from the fedmsg docs break things down into the following 5 major phases:

1) Write fedmsg core routines for sending and receiving. (DONE, in maintenance mode) 2) Start modifying or instrumenting our apps to use fedmsg to send messages. (Mostly done, see the status table for what is done and what is left). 3) Consume messages for statistics. (Done, via datnommer.) 4) Consume messages for user experience. (Done, via the #fedora-fedmsg irc bot, fedmsg-notify, and busmon. 5) Consume messages for interoperability. (Not started. Although, herlo started work on a consumer to update fama trac tickets in response to FAS fedmsg messages.)


Here's a list of things you could work on if you want to help! It is by no means exhaustive, but is just to get the ball rolling. Add things here if you have an idea.

  • Help design the logo.
  • Work on centralizing user notifications preferences by helping with/taking charge of FUSS.
  • Add hooks to *any* project that doesn't already appear as completed on the status table.
  • Work with RH to get bugzilla messages.
    • They'll be providing them via AMQP from qpidd. We'll need to build a fedmsg service called "fedmsg-amqp-bridge" that receives amqp messages and rebroadcasts them to our zeromq bus.
  • Improve the documentation anywhere you see fit! Is it unclear anywhere?
  • Help write a policy for consumers that are acceptable for being hosted in Fedora Infrastructure.
  • Start building consumers that respond and react to events on the bus. Automate our ecosystem!

Triggered Mirroring

dgilmore mentioned that he knows somebody working on this.

  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

See this section on topic namespace from the fedmsg docs. This document on sending messages might also be helpful.