We'd like openQA to emit fedmsg messagess, at least (to start with) when a test completes. This is probably going to be needed for CI-ish release process stuff: emitting a fedmsg will let, for example, releng decide whether or not to release a nightly build based on whether it installs or not.

So far we're not sure of the best way to do this. Personally I think I'd like to have it in openQA itself if that's possible without too much complication: I have posted a comment to an upstream PR for doing dbus signal emission to ask for upstream's opinion there.

Josef had a good idea which unfortunately will not work out: using the post_run_hook() method in os-autoinst. The problem with that is it's run after each test, not each job - so we'd be emitting a whole ton of messages, and also I don't think that method actually knows what job the test it's running from is a part of (which is obviously info we want in the message).

The other way to do this is to have something else which finds out from openQA when a test is done running and sends the fedmsg. To do this at present it would have to poll the API; once upstream merges the dbus signal emission stuff we could also listen for that. There are a few different possibilities down this line. We could just stuff some fedmsg emission into the openqa_trigger code which waits for jobs to complete. The main problem I have with that is that we'd only emit messages for jobs scheduled by the trigger script; this means for instance that if we restarted a test through the web UI, there wouldn't be a fedmsg for it. (It also means if the trigger script dies or is cancelled or anything, no fedmsg).

Another possibility is this: we're probably going to need to write a fedmsg listener to schedule tests when we get a 'compose complete' fedmsg from releng. (This is something taskotron already does, but we can't really have taskotron schedule openQA jobs at present for two reasons - taskotron can't talk to coconut because of the RH firewall, and we don't have a way to do ISO downloading from a remote system yet; you can schedule jobs on an openQA box from some random remote system, but only if the ISO you want to test is already present on the openQA box). That listener could emit messages for the jobs it schedules when they're done. That again has the same problem, though - we don't emit messages for any jobs scheduled any other way.

We could write a dedicated daemon that just sits around looking for completed openQA jobs and sending out fedmsg messages. I just don't really like the idea: it's yet another damn bit of code to look after and it complicates openQA deployment (you have to remember to make sure the daemon is installed and keeps running). But hey, at least we wouldn't have to write it in perl. As mentioned above, at present it would have to poll the API somehow for completed jobs, in The Future it should be able to just listen on dbus.