Accepting as an automatic blocker based on https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers

Is this the first image the triggered this? What is the diff on the packages file between the last one within size limits and this one?

Kevin and Neal both suggested assigning to rishi, so here ya go...

This may well not be the first one - unfortunately relval doesn't check these, so Kamil probably just did it manually while doing validation testing. We'd have to go dig through old images, and we only have two weeks' worth of those :/

I'll file a ticket for myself to have relval check these too...

oh, darn, relval *is* supposed to check these, but we changed the metadata for them (the type is now 'container' not 'docker') and I didn't update the relval config. d'oh. fixing.

So, we set these limits in February 2024, with this note:

"The most recent tarballs for aarch64 and x86_64 are 168M and 189M respectively [1].  A slightly higher size is specified to avoid getting triggered by trivial increases due to the usual content churn as things move forward over time; but still tight enough to ensure that it's increasing for some good reason rather than due to packaging or build system bugs".

It seems we lost track of this quite a while ago though (probably because of the image type change which meant relval stopped checking the size), because the F41 x86_64 image is already 319 MB - https://dl.fedoraproject.org/pub/fedora/linux/releases/41/Container/x86_64/images/Fedora-Container-Toolbox-41-1.4.x86_64.oci.tar.xz . So whatever made them get bigger, it was between Feb 2024 and F41 Final release (October 2024).

(In reply to Adam Williamson from comment #6)
> So whatever made them get bigger, it was between Feb 2024 and F41 Final release (October 2024).

This also shows how "release critical" these max size specifications are. We should probably take a different approach in handling their blocking status, because obviously nothing breaks if they grow over some arbitrary limit, we just prefer to keep them under the limit. That's of course a separate discussion to be had, not in this ticket - I just wanted to mention it, and I'll add to my endless list of stuff to do one day.

yeah, we should probably draw a distinction between media-related and non-media-related limits at least.

(In reply to Adam Williamson from comment #6)
> So, we set these limits in February 2024, with this note:
> 
> "The most recent tarballs for aarch64 and x86_64 are 168M and 189M
> respectively [1].  A slightly higher size is specified to avoid getting
> triggered by trivial increases due to the usual content churn as things move
> forward over time; but still tight enough to ensure that it's increasing for
> some good reason rather than due to packaging or build system bugs".
> 
> It seems we lost track of this quite a while ago though (probably because of
> the image type change which meant relval stopped checking the size), because
> the F41 x86_64 image is already 319 MB -
> https://dl.fedoraproject.org/pub/fedora/linux/releases/41/Container/x86_64/
> images/Fedora-Container-Toolbox-41-1.4.x86_64.oci.tar.xz . So whatever made
> them get bigger, it was between Feb 2024 and F41 Final release (October
> 2024).

Toolbx became a release-blocking deliverable for Fedora 39, when we changed the images from being layered images built by OSBS to being base images built by ImageFactory:
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker

Then for Fedora 40, we changed the build system from ImageFactory to KIWI:
https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages

So, that timeline between February 2024 and Fedora 41 GA made me think of the move to KIWI.  However, that theory was dispelled when I did a quick check of the compressed sizes of the images going back in time:

  rishi@topinka:~$ toolbox create --release 41
  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:41 (387.2MB)? [y/N]: N

  rishi@topinka:~$ toolbox create --release 40
  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:40 (378.2MB)? [y/N]: N

  rishi@topinka:~$ toolbox create --release 39
  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:39 (362.7MB)? [y/N]: N

  rishi@topinka:~$ toolbox create --release 38
  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:38 (317.6MB)? [y/N]: N

  rishi@topinka:~$ toolbox create --release 37
  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:37 (328.5MB)? [y/N]: N

This makes me wonder how the image tarballs for aarch64 and x86_64 came to be 168M and 189M respectively in February 2024?  I have to do some Git archaeology to see if I/we added some legitimate missing/new content to the images after that.

Back in the day with Dockerfile/OSBS and Kickstart/ImageFactory we had some tests that checked the contents of the images.  Sadly, I never got around to restoring those with KIWI.  Those were a way to get some reassurance about what's going into the images.

Anyway, thanks for keeping an eye on the sizes of the fedora-toolbox images, Kamil!

Hi Debarshi, just to clarify - this bug doesn't mandate that the image sizes must go under 200/230 MB limit again. If the toolbox team agrees, we can simply raise the limits (or completely remove them). It's up to the toolbox team, really.

(In reply to Kamil Páral from comment #10)
> Hi Debarshi, just to clarify - this bug doesn't mandate that the image sizes
> must go under 200/230 MB limit again. If the toolbox team agrees, we can
> simply raise the limits (or completely remove them). It's up to the toolbox
> team, really.

Okay, understood!  Still, I would like to at least investigate what happened, so that the original idea behind the image size limits continue to be upheld:
  "... to ensure that it's increasing for some good reason rather than due to packaging or build system bugs"

Marking as a dupe of the tool-created bug, just because that'll make the tool happy in future. Will copy useful bits there.

*** This bug has been marked as a duplicate of bug 2394358 ***