Messaging SIG
From FedoraProject
Contents |
Mission
Create a Messaging infrastructure within the Fedora Project to facilitate communication, interaction, and integration between services within the Fedora Infrastructure.
Members
- Jesse Keating
- Toshio Kuratomi
- Mike Bonnet
- Ricky Zhou
- Luke Macken
- John Palmieri
- Clint Savage
- Brennan Ashton
- Ralph Bean
- Tim Flink
- John Dulaney
Status
We're currently in the planning stage of the SIG. Bringing interested people together to flesh out the who, what, where, when, and how.
Communication
- #fedora-admin and #fedora-devel on Freenode IRC
- Slides from a talk given at Linux Fest Northwest 2009 by Jesse Keating
Schedule
None yet, need to work out a timeline for implementing a Messaging system.
Brainstorming
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?
Proposals
- A proposal for implementing a publish/subscribe notification infrastructure for Fedora
- A 0mq proposal
Tasks
- 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.
For this the following wedges would need to be made to place the services on the bus:
Shims
- NetApp
- Compose
- AutoQA
- PkgDB
- Koji
- Bodi
- SCM
- Bugzilla
- Zabbix
Triggered Mirroring
- 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.
- Message when the NetApps snapmirror is back in sync. Tier 1 mirrors subscribe, and should pull now.
- Message when each Tier 1 mirror has started syncing. Tier 2 mirrors subscribe, and don't pull until the next message.
- 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
Resources
Links to documentation and project pages for the various tools we'll be using.
