On Mon, 2019-06-10 at 09:24 +0900, Tristan Cacqueray wrote: As well as the doc, there is a sample consumer: https://github.com/fedora-infra/fedora-messaging/blob/master/fedora_messa... and a couple of sample config files: https://github.com/fedora-infra/fedora-messaging/blob/master/configs/fedo... https://github.com/fedora-infra/fedora-messaging/blob/master/configs/fedo... that you will probably find useful. Treat this with caution, because it is...sometimes a lie. It is in fact auto-generated from the test cases for the fedmsg_meta_fedora_infrastructure project: https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/ which is where the metadata providers that produce things like the human-readable summaries you get from FMN live. If you maintain a thing that publishes fedmsgs, you are *supposed to* also maintain a provider in fedmsg_meta that can interpret all the fedmsgs your thing publishes, and a test suite for that provider which includes tests for every topic your provider publishes on and useful docstrings for each test. That doc page is then actually built more or less just by gluing all the test docstrings together. However, there is no enforcement of any of this. Which means that it quite often isn't really all in sync. I think there may still be some fedmsg publishers which don't have a metadata provider or tests at all. There are definitely some where a provider and tests exist, but the fedmsg publisher's behaviour has changed a lot since they were written and no-one has updated the provider or the tests, so the doc no longer actually lists the topics on which messages are now being published. I don't really use this list any more because of issues like that... ...this is much more useful, because it is just a log of all the *actual* fedmsgs that have ever been published. It can be a bit unwieldy to work with, but it's not too bad. You can see all Koji messages from the last two days here: https://apps.fedoraproject.org/datagrepper/raw?category=buildsys&delt... You can tweak the 'delta' arg (given in seconds), or use 'start' and 'end' (given as Unix timestamps) instead, to get messages from different periods. Note, datagrepper consumes and publishes *fedmsgs*, not fedora- messaging messages (at least at present). We are currently in the middle of trying to move things over from fedmsg (the old 0MQ-based system) to fedora-messaging (the new AMQP-based system). To aid this, there are bridges in place in both directions: messages published to fedora-mesaging are re-published as fedmsgs, and messages published as fedmsgs are re-published to fedora-messaging. Even for messages that are actually natively published to fedora-messaging, what you see on datagrepper is the result of the AMQP->0MQ bridge: it's not the actual original message, but the re-published fedmsg. AFAIK there is no publicly available 'datagrepper-for-fedora-messaging' ATM, though, so you can't really look at an archive of the actual messages as they're seen on the new system. There is one very important wrinkle you should bear in mind thanks to this: the message format. If you're writing an AMQP consumer in Python, what you'll ultimately get for your consumer to process is a `message` object which is an instance of a fedora_messaging.api.Message() (or a subclass of it - a message schema class). This will have a `body` attribute which should be a dict of the message 'body' - the main meat of the message. If the message was natively published as a fedora-messaging AMQP message, that is indeed what it will be. However, if it was published as a fedmsg, what you get as `message.body` is actually the *entire* fedmsg dict - the whole dict as you see it when you view a message on datagrepper, with a bunch of headers and a 'msg' dict with the real body in it, e.g. https://apps.fedoraproject.org/datagrepper/id?id=2019-633e9879-8974-4ad4-... . To get to what is effectively the 'body' of a fedmsg, you need to take message.body['msg']. This wrinkle is currently under discussion at https://github.com/fedora-infra/fedmsg-migration-tools/issues/20 . I came across this while converting fedmsg consumers to fedora- messaging, and I wrote a little helper to deal with it: https://pagure.io/fedora-qa/fedora_openqa/blob/fedora-messaging/f/fedora_... Whenever you want the body of a message you just run it through that and it should give you the 'true' body. That also means you won't have to worry if the bridge gets changed to fix the bug, that function will still give the correct result. If you want to look at some real-world fedora-messaging consumers, that file contains three consumers for scheduling openQA jobs and reporting their results. Also see the reference config files (the '.toml' files) and the README, at top level of the fedora-messaging branch: https://pagure.io/fedora-qa/fedora_openqa/tree/fedora-messaging You can also look at Bodhi, which has also been converted to fedora- messaging: https://github.com/fedora-infra/bodhi/blob/fde8eefc016b55be76ec6a5298b8b4... the config file for Bodhi is in infra ansible: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodh... Oh, one more wrinkle I had fun with: if you want to use the 'public' credentials for the brokers, be aware that the amqp_url setting and [tls] block settings in the sample config files are correct, but the necessary certificate and key files for the staging broker are not included in the `fedora-messaging` package at present. If you look in /etc/fedora-messaging after installing it you'll see only the files for the production broker are there. If you want to listen to the staging broker, you have to grab the files from a git checkout (they're in the 'configs' dir) and copy them to /etc/fedora-messaging . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net