Learn more about these different git repos.
Other Git URLs
This is kind of a tentative ticket, but I want to write it down to make sure I don't forget.
I'm currently working on a 'missing release blocking images' check for compose-utils. That's easy enough to do. But a kinda logical extension of that would be to check for all images the compose should have included, but which it doesn't because their compose failed.
I haven't looked into this very deeply yet, but at a casual glance doing this outside of Pungi is very hard and would involve duplicating quite a lot of Pungi just to, say, figure out what precise set of deliverables an arbitrary Pungi config file ought to result in. That feels like the wrong way to go about it. I think the right way to go about it would be for Pungi to keep track of that information as it goes along (since it obviously has to figure out what it's actually going to try and build).
So: I guess my initial thought is that a finished Pungi compose's logs should include something like a list of all the things it tried to do, but which failed. I don't wanna get too specific about precisely what this should look like, but to throw out some vague ideas, it would be nice for instance to have IDs for all the failed Koji tasks (as well as of course knowing what each one was meant to produce).
Then compose_utils' job would be pretty simple: just parse the Pungi log and turn it into the appropriate format for the status email.
As a complement to this, @nirik suggests it might be a sane design for it to be Pungi's job to know which images are 'release blocking' and log when one of those is missing, too. Right now two concepts kinda exist in Pungi already:
DOOMED
it does not have a concept of 'release blocking' images, but we could teach it one, much along the lines of the 'failable' concept, and make it Pungi's job to know when one is missing and log it. If we were gonna do that, I guess the 'missing release blocking deliverables' list would simply be a subset of the 'all missing deliverables' list.
Yes, this would be a nice improvement.
First step would be to improve the logging of failed deliverables. Currently in only lists variant and in some case architecture. Now that we have subvariant, it should be included as well.
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160331.n.0/logs/global/pungi.global.log
I think the release blocking should actually be a complement of the failable deliverables. If something is a blocker for a release, it seems like a good idea to have the compose fail if it is not there.
My plan long term is to configure a compose to fail when a release blocking deliverable fails. So the only thing that will be able to fail and have the compose continue is things that are not release blocking. we just do not yet have enough granularity.
I actually wasn't thinking of going quite that far, but I guess I'm not really opposed to it. So at that point all we'd need would be the information about which 'failable' deliverables failed - we wouldn't need to track 'release blocking' deliverables because we'd know that if the compose succeeded, they were all present. We could just send out the information about which non-blocking images failed, for people who care about those.
I have opened a pull request #269 with first improvement. Feedback is welcome.
Can this issue be closed as pr #269 is merged? @lsedlar
To be honest I'm not sure. The logging added in #269 is really not all that useful. It contains only variant, subvariant and architecture for each phase. It's very hard to actually understand it.
Example: https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/logs/global/deliverables.json
Alternatively, we could close this as it's kinda been overtaken by events. That "long-term plan" ausil referred to above? We actually did that, so now composes fail if a critical image compose task fails. Also, failed-composes got written, which does more or less what I wanted outside of pungi (the thing I thought would be too hard). Despite the name, it doesn't only track "failed" composes - it files a ticket for every compose, and lists failed sub-tasks for composes that are overall FINISHED_INCOMPLETE.
FINISHED_INCOMPLETE
So, all the information I wanted when initially filing the ticket is now available. It's just done in a kinda different way to what I envisaged, but it does the job fine.
Login to comment on this ticket.