#337 consider fedora-toolbox a release artifact
Closed: Fixed 2 years ago by petersen. Opened 2 years ago by petersen.

Currently the Fedora release process doesn't track fedora-toolbox container images at all I believe.
While it hasn't been a huge problem, once again it is currently not possible to build
fedora-toolbox images
right now in the buildsystem (I believe fedora-toolbox is actually the only active layered container image shipped for Fedora, though icbw there).

Should we look into having the fedora-toolbox image tracked as part of the release process for the next release? Can it be a release requirement to have an up-to-date fedora-toolbox image available at release time (eg with the latest fedora-repos and fedora-release packages)?

[ps I do feel it is attractive and really preferable to build the official images within Fedora infra/buildsystem, but another alternative could be to build them outside, eg for quay.io (like some of the other toolbox images now available for other distros) - that would avoid depending on the somewhat fragile Fedora container buildsystem...]


At a minimum I think we should at least track it at the WG level on our release checklist.
That might also be sufficient as long as we do remember. :-)

(Well I haven't been forgetting this, but maybe not socializing the problem sufficiently.
This time I was aware of it the last week of Sept (before I went on holiday),
but I again naively assumed initially it might just be a temporary buildsystem glitch -
I guess I am learning the hard way that that is seldom the case...
since containerBuild seems only used by fedora-toolbox.

I've personally been struggling to keep track of the release checklist. If we had better tooling it might be easier - if we used Gitlab, I might create an issue with the checklist, set myself as the assignee, and set a deadline on the issue.

I could probably do something similar with my personal calendar, but I'd prefer it if we had something shared.

I've personally been struggling to keep track of the release checklist. If we had better tooling it might be easier - if we used Gitlab, I might create an issue with the checklist, set myself as the assignee, and set a deadline on the issue.

We can slowly start to "migrate" from here to Fedora's GitLab.

Whether we have a checklist or not is irrelevant if Pungi isn't composing the artifact and pushing it. Nobody should be manually creating such a trivial image.

Metadata Update from @petersen:
- Issue tagged with: meeting

2 years ago

Whether we have a checklist or not is irrelevant if Pungi isn't composing the artifact and pushing it. Nobody should be manually creating such a trivial image.

Right, it is currently manually generated

Metadata Update from @tpopela:
- Issue untagged with: meeting
- Issue tagged with: meeting-request

2 years ago

Workstation WG agrees that we should not release before the toolbx images are ready. Two action items here, for Jens: (a) talk to releng about creating the toolbx images, (b) talk to Fedora QA about creating a blocker criterion to ensure we don't release if the images are not ready.

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request
- Issue assigned to petersen
- Issue tagged with: pending-action

2 years ago

Just adding @rishi for awareness

I have opened

to start discussions on release criteria for fedora-toolbox.

Oh and btw I managed to build new fedora-toolbox images today, thanks to releng people fixing the containerBuild issues.

Thanks for working on this, @petersen I had in the past informally discussed making working Toolbx a release blocking criterion with various folks (including @sumantrom from Fedora QE), and people seemed generally receptive, so I am very happy that you are trying to push this through.

A few random thoughts below...

We should also include don't break Toolbx, beyond having an updated fedora-toolbox image, as a release blocking criterion because it touches too many different parts of the operating system. eg., changes to Fedora's Kerberos stack can cause Kerberos to stop working inside Toolbx containers, changes to the sysctl(8) configuration can break ping(8), changes in Mutter can break graphical applications, etc.. It's a growing list that's not easy to keep up with without some extra diligence. :)

So, among other things, when a Change is submitted and evaluated, there should be a separate criterion about whether and how it impacts Toolbx. Just like we currently have criteria that ask whether the Change requires changes to the Fedora Packaging Guidelines, impacts Release Engineering, trademarks, etc..

Secondly, if the images are going to be generated by Release Engineering, then will they be still defined in terms of a Docker/Containerfile as they are today? I am not entirely sure how the fedora base images are currently defined and built today, but, as far as I can make out, the kickstart files in fedora-kickstarts play a role. eg., fedora-container-base.ks.

The fedora-toolbox images are currently defined as a Docker/Containerfile, both upstream and downstream. There's some value in this.

A Docker/Containerfile ensures a workflow that's widely known and easy to use with podman build. While the Fedora (and the RHEL) images are built and published from copies maintained downstream on Fedora's (and Red Hat's) infrastructure, various other distributors don't have their own infrastructure and those images are built and published straight from the upstream Git repository to Docker Hub or Quay. As an upstream Toolbx contributor, who needs to ensure that the toolbox(1) binary works with all those images, it's really convenient to have all of them at least be defined in the same format. It makes it easy to understand what's going on, test the images as part of the upstream CI, etc..

Anyway, this is already too long, so I will stop now. :)

I am +1 to having a criteria change. I will propose one this week on test and see how that goes.

@sumantrom it doesn't seem like you ever did propose a criterion?

@rishi is proposing a system wide change for F39:

https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker

OK for us to close this, @petersen ?

Metadata Update from @aday:
- Issue untagged with: pending-action

2 years ago

Yes, let's close now.

From here on it seems better to track the Change proposal.

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

2 years ago

we do have a criteria proposal that's being kicked around on test@ , but it's rather interdependent with the actual implementation. that's all getting sorted out in the fesco ticket and the releng ticket, though, so should be OK.

Log in to comment on this ticket.

Metadata