Increase the metadata size limit to 128MB

[barthalion]

Flathub has hit the 10MB limit in 2022, and we had to drop some CPU architectures from the main summary to subsummaries, effectively cutting off users running too old Flatpak version. Despite that, the main summary containing only x86_64 is already at 7MB. As this is eventually going to happen to subsummaries as well, preemptively bump the limit 12 times.

It takes between 2 and 3 years for a change like this to roll out across Linux distibutions so the best time for this was yesterday.

fixes #2715

[openshift-ci]

Hi @barthalion. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[barthalion]

Looks like a single test hardcodes the size to test against the modified variable, I will get that fixed later today.

[dbnicholson]

/ok-to-test

[barthalion]

I don't think I understand how test-pull-large-metadata is supposed to work. It overwrites a commit object with zeroes, so it ends up complaining about a corrupted object, although only if I change its size from 20MB?

[dbnicholson]

I don't think I understand how test-pull-large-metadata is supposed to work. It overwrites a commit object with zeroes, so it ends up complaining about a corrupted object, although only if I change its size from 20MB?

The pull is going to fail regardless because the commit object is corrupted. However, what the test is checking for is that it explicitly fails with a size too big error. That check happens before the commit object is read, so you'd get an exceeded maximum error in the case that the object is too big. If it's not too big (> 128MB with your change), then you'll get a Corrupted commit object error.

[cgwalters]

Marking as needs work

[barthalion]

https://github.com/ostreedev/ostree/actions/runs/5256285362/jobs/9497375004?pr=2865 looks like a fluke.

[dbnicholson]

https://github.com/ostreedev/ostree/actions/runs/5256285362/jobs/9497375004?pr=2865 looks like a fluke.

Indeed. test-concurrency.py occasionally fails for as yet undetermined reasons #2038. I restarted the jobs so it would get green but I don't think there are any further issues.

Issues were addressed