#140 Workstation Live image is oversize
Closed: Fixed 3 years ago by chrismurphy. Opened 3 years ago by kparal.

Fedora-Workstation-Live-x86_64-32-1.4.iso has 2022113280 bytes, while its limit is 2000000000 bytes:
https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking

The bug is reported also here:
https://bugzilla.redhat.com/show_bug.cgi?id=1826156

That is an automatic blocker. We need to deal with it ASAP, so that you either raise the limit and we can keep testing the images, or you quickly trim something and we spin new ones. What is your decision?

There is an older related ticket #47. The same suggestion I provided in there still applies. If you're OK with raising the limit, there should be enough headroom so that we don't need to go through this last minute process frequently, it delays the release process. I suggested 4.7 GB (DVD size). If you want to keep the existing limit, we need to start trimming quickly. The Workstation Live Beta size was 1949515776.


+1 to raising the limit to 4.7 GB. Adding to today's meeting agenda as well.

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

3 years ago

-rw-rw----. 1 chris chris 1961017344 Apr 15 20:54 Fedora-Workstation-Live-x86_64-32-1.3.iso
2022113280−1961017344=61095936=61M

The list of changes from 1.3 to 1.4:
https://pagure.io/releng/issue/9403#comment-643176

My guess, without having looked, is maybe backgrounds has an extra image?

+1 to raising the limit

I'm okay with 4GiB like most other spins at this point.

I think looking into this Silverblue compose log https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200420.0/logs/x86_64/Silverblue/ostree-1/create-ostree-repo.log , f32-backgrounds-animated can be that package which increased size.

WG has not approved a size increase. We will continue discussion next week.

Decision from today's meeting, by unanimous consent, is that f32-backgrounds-animated must be removed from the compose.

Gah.

I actually worried about this before doing RC 4, so I checked - it looked like RC3's Workstation live was 1.8GB and the -backgrounds-animated package size is reported by Koji as 56MB so I though it would be fine :( Sorry, I should've run a test live image build too...

Grah. Good old MB vs. MiB biting me in the ass again. https://dl.fedoraproject.org/pub/alt/stage/32_RC-1.3/Workstation/x86_64/iso/ reports the size as '1.8G' but as @chrismurphy says it's 1961017344 bytes :( Didn't realize the web listing was giving me power-of-2...

cmurf | mboddu: bcotton: WG did get close to bumping to 4G but there were concerns about the process and whether or not we'd actually ever establish one, or just let e.g. 2G of fonts appear in F33
cmurf | i agree with kparal that living within 100M of the limit is just asking for trouble
mboddu | cmurf: Thats a good concern, we should look at current sizes and establish a policy around them, maybe like not more +20% from what we have right now

@adamwill @mohanboddu

20% bigger suggests ~2.4G image size for Workstation Live. That is at the very high end of estimates if we were to move to a zstd plain squashfs image, for example. Median is about 5%.

And instead of fonts, a bunch of applications were to be added. Or even substituting RPM apps for flatpak versions. This has both releng and QA impacts. Maybe each team can list concerns with arbitrarily larger image size, and suggest their constraints in this ticket? e.g. QA maybe doesn't care if the apps get bigger, whereas would care if there are 5 more apps that need to "withstand a basic functionality test", per final release criterion? And then Workstation WG can circle back to this and incorporate. Another idea, I can invite Adam and Mohan to a future Workstation WG meeting on the topic and figure something out. Alternatives?

How about 2GiB? :)

Actually I would like to work on pushing the size down more if possible, but overall it is an uphill battle with software tending to grow in size.

In this context I have been meaning to suggest dropping qt* from the Live image (afaict nothing needs Qt in Live except adwaita-qt*: some weak/rich deps might be needed for them).
Also I personally feel we don't need virt preinstalled in Live, though others might disagree -- virt is really important, but not every install needs it.

And instead of fonts, a bunch of applications were to be added. Or even substituting RPM apps for flatpak versions.

It seems you're trying to use the size constraint as a safeguard against multiple other things that can go wrong. I understand why, but it would be good to have a better process for it, and leave the size check related to size only.

In my ideal world, all Edition owners have a complete go/no-go power over their Edition. Every hypothetical problem wouldn't need to be listed in release criteria. If something wrong happened like "1 GB of fonts was suddenly added to the image", the particular WG would simply discuss the matter and declare whether they're OK with shipping it or not. This "full WG decision power" is not completely achievable at the moment, because it not only blocks that Edition, but the whole Fedora release. So this is an approach which we can take when Edition releases are fully decoupled (as was proposed many years ago).

But perhaps we can define a limited process applicable to current joint releases? For example, any Edition owner would be able to delay the whole Fedora release, because there is something in their Edition which they disagree with and want to quickly fix. But the maximum delay would be 2 weeks, shared among all Editions. So if Workstation delays Fedora by 1 week, anyone (including Workstation) can delay Fedora by 1 additional week. Then the maximum delay is depleted, no more delays. These delays can work in addition to regular release slips, or not. These delays might be required to be announced at least X (e.g. 5) days before Final Go/NoGo, unless the problem occurred in those last X days. This would motivate WGs to care about the problems during the release cycle and not postpone it to the last minute. Disclaimer: this whole proposal is just an immediate rough idea.

TL;DR: Release criteria should contain hard rules ("size under 4GB"), WGs should judge the intent ("adding 1GB of apps good/intentional, adding 1GB of fonts bad/mistake"). I think we can come up with some processes to let WGs have this decision power (with limits).

TL;DR: Release criteria should contain hard rules ("size under 4GB"), WGs should judge the intent ("adding 1GB of apps good/intentional, adding 1GB of fonts bad/mistake"). I think we can come up with some processes to let WGs have this decision power (with limits).

For what it's worth, I consider 1GB of fonts to be a better add than 1GB of flatpak apps. We're stingy on i18n support on the media, and I'd really like to see that fixed someday...

For what it's worth, I consider 1GB of fonts to be a better add than 1GB of flatpak apps. We're stingy on i18n support on the media, and I'd really like to see that fixed someday...

Neal, that was an example! :-) That's exactly why I don't want to put this stuff into release criteria. It needs to be considered in the context of a particular Edition, it will change in time, and it will likely be a contentious issue.

Well we have Noto, that is big and it's supposed to have broad i18n coverage, right?

Qt being in Workstation was part of the core vision of Workstation at the start, it's in the tech spec:

"The workstation will ship with a single theme, which will have support for the included toolkits: gtk3, qt and gtk2"

I think we got GTK+ 2 out of there, but the idea that you could count Qt as part of the Workstation "platform" was considered significant at the time IIRC.

FWIW: The release blocking Workstation aarch64 image max size is 8G, it's raw.xz format. Server max is 4.7G. Many have no max size listed. (And off topic, but Workstation netinstall probably shouldn't be in this list, I think it's not release blocking for a while?)

(And off topic, but Workstation netinstall probably shouldn't be in this list, I think it's not release blocking for a while?)

It's no longer even produced. Ping @bcotton.

(And off topic, but Workstation netinstall probably shouldn't be in this list, I think it's not release blocking for a while?)

It's no longer even produced. Ping @bcotton.

Removed, thanks

Hypothetical: on image review test day, the actual image size comes out to 2.2G, and it is perfect in every way. Further, suppose at some later date prior to release, the image size increases. Do we want a warning if it jumps 100M? 500M? 1.8G?

Currently QA has a script that autofiles an oversized ISO bug. The value could be set per release based on the image review test day image size plus some sane fudge factor. Yes please? Overkill?

An alternative is to just set the max ISO size to 4G, and then we track this ourselves based on the test day results, and hopefully no bad luck causing a large jump in size.

cmurf | ok so right now you just hardwire the size into relval and rebuild if it changes
cmurf | what about (a) see whether this image size test day thing even happens, let alone consistently, and (b) one of its outputs is to submit a PR for relval to change the WARNON size?
adamw | that works too
adamw | cutting releases is really not difficult, it's really about 5 minutes, the other 20 are doing koji builds and a bodhi update and sshing into the servers and updating the packages there :)
adamw | but it would also be easy to change it to use a file, so, meh
adamw | if you file ticket(s) at https://pagure.io/fedora-qa/relval i will Do Something

If we commit to the image review test day concept, I'll file the ticket for @adamwill "to do something" .

Part of the instructions for the test day should include the step "update the warnon ISO file size in this file <URL>".

Qt being in Workstation was part of the core vision of Workstation at the start, it's in the tech spec:
"The workstation will ship with a single theme, which will have support for the included toolkits: gtk3, qt and gtk2"
I think we got GTK+ 2 out of there, but the idea that you could count Qt as part of the Workstation "platform" was considered significant at the time IIRC.

Right, but it seems theming is the primary (only?) reason to pre-install Qt, if we had appropriate weak/dependencies what made Qt pull in the adwaita theme automatically, then it seems to me the requirement could be dropped. We would need to check how that would interact with the KDE Spin though.

Anyway I plan to open a separate ticket later to discuss this.

[..] Further, suppose at some later date prior to release, the image size increases. Do we want a warning if it jumps 100M? 500M? 1.8G?

I think we should have a hard limit in place per release which we can review from time to time.
I would actually prefer having a soft limit and a hard limit. So we get warned when we go over the soft limit and it becomes a blocker if we should go over the hard limit but the soft limit should help avoid that.

Currently QA has a script that autofiles an oversized ISO bug. The value could be set per release based on the image review test day image size plus some sane fudge factor.

Yes please

An alternative is to just set the max ISO size to 4G, and then we track this ourselves based on the test day results, and hopefully no bad luck causing a large jump in size.

I feel we should proactively keep the size down, if we are going to relax the limit then we need to continuously monitor the actual size.

"Right, but it seems theming is the primary (only?) reason to pre-install Qt"

I don't think so. My recollection is that it was desired to position Workstation such that it was OK to write apps in Qt targeting Workstation as a platform.

The 'workstation edition image review test day' needs an leader/owner to manage the test day and report on the findings. And then this issue can be closed in favor of the new QA issue for that test day.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

3 years ago

Let's just use the GNOME 3.38 test day for this and I'll make sure we schedule it appropriately so that there's at least a week before the beta freeze to get any fixes in.

OK I think this can be closed.

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

3 years ago

Login to comment on this ticket.

Metadata