We want to hook all the services in Fedora Infrastructure up to send messages to one another over a message bus instead of communicating with each other in the heterogenous, “Rube-Goldberg” ways they do now.
fedmsg (Fedora-Messaging) is a python package and API used around Fedora Infrastructure to send and receive messages to and from applications. See Overview for a thorough introduction.
The quickest way to see what the bus is all about is to jump into #fedora-fedmsg on the freenode network. There’s a firehose bot there echoing messages to channel.
import fedmsg
# Yield messages as they're available from a generator
for name, endpoint, topic, msg in fedmsg.tail_messages():
print topic, msg
$ fedmsg-tail --really-pretty
See Development on setting up your environment and workflow.
import fedmsg
fedmsg.publish(topic='testing', modname='test', msg={
'test': "Hello World",
})
$ echo "Hello World." | fedmsg-logger --modname=git --topic=repo.update
$ echo '{"a": 1}' | fedmsg-logger --json-input
$ fedmsg-logger --message="This is a message."
$ fedmsg-logger --message='{"a": 1}' --json-input
The source for this document can be found on github. The issue tracker can be found there, too.
Almost all discussion happens in #fedora-apps on the freenode network. There is also a mailing list that doesn’t have much traffic.
Start writing fedmsg core.
Use fedmsg to send messages from existing services (koji, bodhi, pkgdb, fas, etc...). The status of this is kept in FedMsg Status Table and Bus Topology.
Consume messages for statistics, i.e. an independent statistics webapp. This will some day be the responsibility of datanommer. See FedMsg Status Table for its status in our infrastructure.
Consume messages for user experience, i.e. any or all of rss, email, gnome-shell notifications, javascript notifications in FI webapps. One example of this is lmacken’s dbus-based fedmsg-notify.
Consume messages for service interoperability: for example, have koji invalidate it’s cache when it sees pkgdb messages go by on the bus. Or, have the mirrors starts to sync once a new compose of branched or rawhide is complete.
This comes last because we want to make sure that message-sending works and is reliable before we start making existing services depend on it for their functioning.