There is a common request concerning what message topics pass through a given exchange. Thus, similar to what was planned to show off STOMP support, we should build a web app (alongside other core pulse web apps like pulseguardian) that lists active exchanges (to which at least one message is posted every N seconds) and recent message topics.

Pulse Guardian is getting a bit misnamed now, but it's the public face of pulse.mozilla.org, so this app should be part of it, I guess.

Furthermore, we could display the last few messages from each exchange, to help people writing clients. This is better than some static examples, which will fall out of date.

(In reply to Mark Côté [:mcote] from comment #2) > Furthermore, we could display the last few messages from each exchange, to > help people writing clients. This is better than some static examples, > which will fall out of date. +1 to this, would be a big help in debugging.

An API that could return list of exchanges and possibly queues would be nice. You can build UI for the API later... But I can easily imagine other uses for such an API. With respect to maintaining a list of topics/routing-keys I would like to note that in in taskcluster we slugids (unpadded URL-safe base64 encoded uuids) in our topics, so trying to track the list of topic might be a problem. Exchanges I've created for treeherder (not deployed yet, see bug 1016117) has the revision_hash in the routing-key. Needless to say that uuids and revision_hash can be fairly unique. > Furthermore, we could display the last few messages from each exchange, to help people writing clients. Just don't try to save the messages in a database, but keep them in unstable process memory and you'll be fine.

This PR doesn't address everything in this bug, but it seems like it belongs here as part of the solution.

I'll re-add the other PR once I've rebased it on top of this one.

Comment on attachment 8749845 [details] management api class into library Looking good; left a few comments on the PR. Please reset the review flag when you've addressed them.

Comment on attachment 8749845 [details] management api class into library OK, I made adjustments according to your feedback. Thanks. Back to you! :)

First PR merged and pushed: https://github.com/mozilla/pulseguardian/commit/16de5f953d71dcac7490be3eb9acec36e6c98244

Comment on attachment 8750979 [details] part 2 - adding bindings There's a bug in the code that creates the binding objects, as commented in the PR. Also, please add some tests (including one that specifically tests for this problem :).

Comment on attachment 8750979 [details] part 2 - adding bindings OK, I've made the fixes and added tests for this now. Please review at your leisure.

Comment on attachment 8750979 [details] part 2 - adding bindings Looking good! Just a few nits.

Comment on attachment 8750979 [details] part 2 - adding bindings Only a couple tiny things. I rebased your commit, pushed it, and deployed it. I forgot to actually fix the nits I pointed out, though, so I added a follow-up commit. https://github.com/mozilla/pulseguardian/commit/eab34347d421c7898ea148ce9a90199d39da1d28 https://github.com/mozilla/pulseguardian/commit/d44b3acc0f11cc0d5e609ea47dbdb97626bc33ae

As I mentioned in the PR, there's a Travis failure, but it didn't seem related to your changes... I'll investigate separately.

Ah, it was actually a change in the tests that broke things, in that config variables weren't being overridden early enough. Now that we use environment variables, though, we should probably be using those instead of directly overriding config. Anyway that's a separate bug.