On Wed, 2017-07-05 at 15:04 -0600, Chris Murphy wrote: > On Wed, Jul 5, 2017 at 12:50 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > So... this prompts a question in my head. I understand we don't block > > release for non-blocking spins. That is obvious. > > > > What is not obvious to me is if we would go back and do a compose > > later for those spins that are impacted by this. It is one thing to > > skip a spin if the maintainer has not kept up with the release and is > > otherwise negligent. It is quite another to tell them "too bad..." if > > the spin isn't composed for something completely out of their control > > such as an infrastructure issue. That, to me, would be discounting > > the work they've done throughout the release to maintain and test > > their spin. > > > > Do we have that ability to do a post-GA compose for those spins in > > such cases and do we plan to do so? > > Nope. This came up last cycle or two where compose had a weird bug > preventing umount of the installation root fs image file, resulting in > a corrupt file system and ensuing boot failure of the ISO. And > actually there were some non-release blocking images that we simply > did not ship because of those failures, and they were not respun, and > releng said we couldn't even use a prior successfully built ISO. > > I don't recall the reason, something to do with either signing or > metadata or something... I think it's known an alternative would be > nice, especially given the big pile of images we're creating now, but > I don't know what work is needed. Before Pungi 4, the concept of a compose was fairly abstract. There was very little that you could point at and call 'the compose'; because there was no compose-level metadata or PDC or anything like that, we could re-run the compose command for a single specific image and stuff it into the tree with the other images. With Pungi 4 we really can't do that any more. Composes have a much more solid identity as an actual thing. 'A compose' has a compose ID, production composes have a label, and these can't really be duplicated. There is a bunch of metadata which is produced for the compose *as a whole*; if we do a compose where we try 10 images and 1 fails, the metadata for that compose will list 9 images. If we then ran another compose just to produce that 1 missing image (with properties as similar as possible to the original compose), the metadata for the new compose would include just that 1 image, or all 10 images, and there is no way to somehow 'edit in' the information about the new image to the original compose's metadata (besides doing it by hand or hacking up a script or something, both of which would be error-prone). It's also not actually that easy just to respin a single image; Pungi 4 isn't really built to do that (you'd have to create a new Pungi compose config file each time you wanted to do it), and releng really doesn't want to do it manually below the Pungi level any more in case of inconsistencies or errors. See the metadata for the RC-1.4 compose here: https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170703.0/compose/metadata/ Note that for dumb reasons that I hate we actually strip the metadata from the final compose when it's actually approved and shipped out to mirrors, but when a compose completes, the metadata related to that compose is uploaded to PDC: https://pdc.fedoraproject.org/ . Once that's done it's not expected, and it may in fact be impossible, for that metadata to be edited, and it's never removed. So even though the metadata for Alpha, Beta and Final composes can't be found on the mirrors with them, it *can* be seen in PDC. However, as I said before, we *do* have some ways we can unofficially provide 'missing' images. They just can't be a full part of the official release. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
