#11399 Add container/fedora-toolbox as a Fedora Linux 39 release-blocking deliverable
Closed: Fixed 9 months ago by humaton. Opened a year ago by rishi.

  • Describe the issue

This is the successor to:
https://pagure.io/releng/issue/11189

... and here is the proposed Fedora 39 Change:
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker

We want to ensure that there are up to date fedora-toolbox OCI images published on registry.fedoraproject.org as release-blocking deliverables at critical points in the development schedule, just like the installation ISOs for the Editions from download.fedoraproject.org.

This must at least happen when an upcoming Fedora release is branched from Rawhide, and for the Beta and Final release candidates. If possible, they should be updated more frequently as part of the nightly composes.

We do not expect this to happen after a Fedora release has gone GA.

  • When do you need this? (2023/08/08)

We need this by the Change completion deadline or before Fedora 39 is branched from Rawhide, whichever is earlier. As per the schedule, both of those are currently set to happen on the 8th of August 2023.

  • When is this no longer needed or useful? (YYYY/MM/DD)

n/a

  • If we cannot complete your request, what is the impact?

The proposed Fedora 39 Change won't be implemented:
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker

... and Toolbx environments won't get closer to the reliability of interactive command line environments running directly on the host operating system.


Metadata Update from @humaton:
- Issue tagged with: change-ack, changes, f39, high-gain, high-trouble

a year ago

So, whats the plan here? :)

That deliverable isn't made as part of our normal compose process. Is the intention that we move it in to be composed nightly with the rest of the compose process and if it fails, fail the compose?
I am not sure pungi can do this, but it might be possible. The base and base-minimal images are made from kickstart files, I don't think we produce anything direct from Dockerfiles.

Or is the intention/plan that we simply have QE check / test it and if it's not available, we are 'no-go' until it is?

I think that was my question in the older ticket.

So, whats the plan here? :)

That deliverable isn't made as part of our normal compose process. Is the intention that we move it in to be composed nightly with the rest of the compose process and if it fails, fail the compose?
I am not sure pungi can do this, but it might be possible. The base and base-minimal images are made from kickstart files, I don't think we produce anything direct from Dockerfiles.

The fedora-toolbox images are currently defined as a Docker/Containerfile, both upstream and downstream. There's some value in this because a Docker/Containerfile ensures a workflow that's widely known and easy to use with podman build as part of the upstream CI.

Is there no way to build the images as part of the normal compose process unless they are defined in fedora-kickstarts? Maybe a fedpkg container-build can be snuck in somewhere?

I think the most tricky milestone is the branching. Even more so than the Beta and Final release candidates.

Currently, one has to remember to jump in after branching is done, and fire off a fedpkg container-build. Until that happens and the image makes its way to registry.fedoraproject.org, folks using Toolbx on Fedora Branched/Rawhide are left in this odd state that leads to unhappy bug reports. Needless to say, we aren't always prompt to trigger the build manually, which can lead to an extended period of not having the image.

It would be a big help if Release Engineering could do this as part of their usual branching checklist.

Or is the intention/plan that we simply have QE check / test it and if it's not available, we are 'no-go' until it is?

I suppose that could work for the Beta and Final release candidates. Although, ideally, if an RPM is tagged into a new release candidate during the freezes, then the same should happen for the fedora-toolbox image. I have no idea how feasible it is for someone who is not in Release Engineering to tag in an RPM for the image, and fire off a fedpkg container-build.

At today's weekly meeting, we agreed that adding a new manual step to the release process is a last resort. We will investigate how this can be made part of our composes using container-build..

Metadata Update from @humaton:
- Issue assigned to humaton

a year ago

So the Change for this was accepted without the releng side of things being fully worked out (unless that was worked out but this ticket wasn't updated). I'm a bit concerned about that. See https://pagure.io/fesco/issue/3002 .

Oh, my bad
so there was a discussion on devel-list about using Kickstart to build the container. The change requester agreed. Here is pr with the kickstart https://pagure.io/fedora-kickstarts/pull-request/964

ah, great. that seems like a reasonable way to cover it. then we can just put in the compose process like any other kickstart-based task, right, and mark it as fatal so the compose fails if it fails to build? and then we just need to figure out a process for publishing it to the registry when it's done...

ah, great. that seems like a reasonable way to cover it. then we can just put in the compose process like any other kickstart-based task, right, and mark it as fatal so the compose fails if it fails to build?

That is the basic idea. I would like to get changes to config and script done together with the kickstart this week.

and then we just need to figure out a process for publishing it to the registry when it's done...

We use this script to sync the base images. It needs some updates to include the toolbox and we should be done.

Here is pr with the kickstart https://pagure.io/fedora-kickstarts/pull-request/964

Thanks for that reference. I had somehow missed the creation of that pull request and was beginning to wonder like @adamwill

Hi @rishi,

can you check if the naming of the new image is ok? Once this PR gets merged we will start composing nightlies with the container image. https://pagure.io/pungi-fedora/pull-request/1179

Yeah, so looks like the name is good. :)

Yep, for future reference, I'm putting the link to the comment where Rishi explained the naming convention: https://pagure.io/pungi-fedora/pull-request/1179#comment-189097.

Afaict the toolbox image is not in Rawhide composes yet.

That is the basic idea. I would like to get changes to config

which is now done it appears.

and script done

What changes would be needed to it?

We use this script to sync the base images. It needs some updates to include the toolbox and we should be done.

I think this is pending, but the image is needed first I suppose.

Thanks to @humaton the rawhide compose is now generating fedora-toolbox:39 since yesterday!

I think the next step is to get the image pushed to the Fedora Registry as noted in https://pagure.io/releng/issue/11399#comment-862130

After this PR, we will now be able to see fedora-toolbox images (updates-candidate) on registries such as registry.fedoraproject.org etc.

Toolbox is part of the regular composes now. Closing.

Metadata Update from @humaton:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

9 months ago

Login to comment on this ticket.

Metadata