Hello Dennis,

I believe we internally already have support in run-distill (which is part which wasn't opensourced yet). Message is being sent every time that compose has finished, been altered, or failed.

We might want to strip run-distill from e.g. composedb support. And opensource it as well.

Lubos

This is obviously something we (QA) are interested in - obviously we want a nice tight loop between composes completing and automated tests kicking off.

I've been looking at this for openQA and as a first thought at least, it would be useful to get messages something like this:

• A message when the entire compose process kicks off specifying what deliverables will actually be built
• A message each time any individual deliverable from the compose is done (and/or, perhaps, available)
• A message each time any individual deliverable from the compose fails to build
• A message when the entire compose is done; I think ideally the URL for this message (the one you can get via fedmsg.meta.msg2link) would be the new file that lists the outputs of the compose, or at least if the way to derive the location of that file from the URL could be relied upon to always be exactly the same

the others on the team might have their own thoughts, these are just the ones that seem useful to me on initial thinking about how to do the integration.

We're using a notification callback (pungi runs an external script to send a message) internally in Red Hat. It notifies about compose start/finish/fail.

I'm not sure if you should be testing unfinished composes.
They should take roughly 2 hours, which is reasonable.
Also testing something that may fail could lead to overloading your test systems with potentially useless tests (from my POV, only tests on finished composes make sense).

Lubos, can you port it to upstream?

It's fairly common in Fedora for, say, the boot.iso compose to succeed but some or all live composes to fail. In that case we still want to be testing the boot.iso, and there's no reason to wait for the lives and ARM images and cloud images to be done before we start testing the boot.iso.

We can work with just a signal when the whole compose is done, and in some ways it's easier, but it would be nice to be able to run some tests as soon as the image is available.

If the compose really will only take two hours that's definitely an improvement too, but allow me to be sceptical till I see it :P Right now a full Fedora compose is ~8 hours, I believe.

(sorry, can't add comments) - we definitely would want to be able to distinguish between 'the entire compose process failed and there are no images' and 'the compose process finished and a couple of images failed to build, but most of them are there'. It would be annoying for both of those states to be represented simply as 'fail' or something.

Hello Adam,

do you need to know it on the message level? It's simple to see message "compose failed". And check images.json in compose/metadata to see what everything is done. At least for a short term and see how that works.

Lubos

Hello Adam,

do you need to know it on the message level? It's simple to see message "compose failed". And check images.json in compose/metadata to see what everything is done. At least for a short term and see how that works.

Lubos

Hello Adam,

do you need to know it on the message level? It's simple to see message "compose failed". And check images.json in compose/metadata to see what everything is done. At least for a short term and see how that works.

Lubos

We don't need to know, sure. It's possible to work with a design where we wait for the entire compose then go read images.json. It just means we can't test images as soon as they're done. How annoying that's going to be heavily depends on how long the entire compose process is, I guess.

I have opened pull request #68 to add support for sending messages. In its current form it only sends a message when whole compose starts or finishes (either successfully or not) and when a phase starts or finishes. The second commit adds more messages when creating ISOs – first one announcing what images are to be built, then one message per image to announce if it succeeded or failed. Example here