releng

#12086 Combine the three post-release stable composes: updates, cloud, container
Opened by adamwill. Modified

Open
Close Issue

  • Describe the issue
    We currently have three separate composes doing more or less the same job ("produce some deliverables updated with the latest content for stable releases"): the updates composes run by Bodhi (https://kojipkgs.fedoraproject.org/compose/updates/ ), the cloud composes (https://kojipkgs.fedoraproject.org/compose/cloud/ ), and the container composes (https://kojipkgs.fedoraproject.org/compose/container/ ). It might be nice if we could combine these into one single compose flow so we have less complexity to worry about.

  • When do you need this? (YYYY/MM/DD)
    No specific time, it's an RFE.

  • When is this no longer needed or useful? (YYYY/MM/DD)
    When we get a new box of kornflakes?

  • If we cannot complete your request, what is the impact?
    We'll continue to have three separate post-release stable compose flows to keep track of (not even counting IoT or FCOS composes).

@siosm @kevin @ngompa

My understanding is that the cloud and container composes are on different cadences...

My understanding is that the cloud and container composes are on different cadences...

Do they need to be though?

ultimately we run all three daily, AIUI. we run one updates compose per release per day, and the cloud and container composes are "nightlies", i.e. again we run one per day per active stable release.

they don't all run at the same time, but I don't think that's terribly important.

my initial thought here would be to extend the Bodhi compose to include cloud and container images, BTW. that seems the nicest option. then we can drop all the per-branch scripts and stuff (though we still have the rather funky 'yo dawg i heard you liked templates so I put a template in your template' thing going on with the pungi compose config file, but never mind).

then my https://pagure.io/releng/issue/12082 could build on top of that and perhaps publish all the content from that combined compose (container and cloud images)...it could even be part of bodhi, I guess, but I don't think it needs to be.
Edited by adamwill

Metadata Update from @phsmoura:
- Issue tagged with: medium-gain, medium-trouble, ops

I'm not opposed to moving this all to bodhi.

I guess they would all be failable?

It would add time to bodhi composes/updates pushes... The containers are pretty quick I think, cloud I am not so sure on.

Cloud seems to be very fast also - the most recent one took all of 19 minutes.

I guess we could try doing it and just see how much longer it takes, my guess is it might not actually take any longer at all now we added the atomic desktop OCIs, since I think those phases (kiwibuild for cloud and container images, ostree_container for atomic desktop OCIs) could run in parallel and kiwibuild would be done first. But I'm not 100% sure.

the drawback would be that, while we're still using the current sync script, it would just publish the images from whichever tasks happened most recently before the script was run...so it might be a bit random exactly what got pushed, depending on the timing. probably doesn't matter much, though, since the images should all be basically the same if we don't mess anything up. once we move to a compose-based sync script that wouldn't be an issue.
Metadata
None

medium-gain medium-trouble ops

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.