releng/tickets

Fork 2

Combine the three post-release stable composes: updates, cloud, container #12086

New issue

Open

opened 2024-04-30 16:43:28 +00:00 by adamwill · 10 comments

adamwill commented

2024-04-30 16:43:28 +00:00

Member

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).

* 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).

adamwill commented

2024-04-30 16:44:22 +00:00

Author

Member

@siosm @kevin @ngompa

ngompa commented

2024-04-30 16:46:37 +00:00

Member

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

pbrobinson commented

2024-04-30 16:57:32 +00:00

Member

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

Do they need to be though?

> My understanding is that the cloud and container composes are on different cadences... Do they need to be though?

adamwill commented

2024-04-30 17:35:33 +00:00

Author

Member

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.

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.

adamwill commented

2024-04-30 17:38:09 +00:00

Author

Member

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.

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.

phsmoura commented

2024-04-30 19:09:15 +00:00

Metadata Update from @phsmoura:

Issue tagged with: medium-gain, medium-trouble, ops

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

kevin commented

2024-05-02 21:00:26 +00:00

Owner

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.

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.

adamwill commented

2024-05-02 22:46:53 +00:00

Author

Member

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.

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.

humaton added

and removed

labels

2026-08-06 09:22:43 +00:00

patrikp added this to the Backlog project

2026-08-06 09:23:05 +00:00

jnsamyak commented

2026-08-06 09:26:35 +00:00

Owner

Before try extending the Bodhi compose to pull in cloud + container images, get real numbers on how much time it adds to the updates compose, check if the kiwibuild/ostree_container phases can actually run in parallel, and note any failability/rollback implications of merging these flows. As pointers for spike, and finally come up with an actionable plan.

We talked about this in the releng backlog refinement call today, and the general feeling was this is worth pursuing, but before going forward with actionavle items to an approach we should do a spike to scope it out properly. Before try extending the Bodhi compose to pull in cloud + container images, get real numbers on how much time it adds to the updates compose, check if the kiwibuild/ostree_container phases can actually run in parallel, and note any failability/rollback implications of merging these flows. As pointers for spike, and finally come up with an actionable plan.

jnsamyak commented

2026-08-06 09:27:30 +00:00

Owner

Any of relengers will try to take this spike in upcoming sprints, community investigation are also welcome.

jnsamyak added the

points

label

2026-08-10 14:14:45 +00:00

jnsamyak started working

2026-08-10 14:14:45 +00:00

jnsamyak modified the project from Backlog to Current Sprint ( 2026-08-10 to 2026-08-23 )

2026-08-10 14:14:49 +00:00