Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

osbuild: support more platforms; reduce memory usage for mkfs.erofs #4025

Merged
merged 15 commits into from
Feb 17, 2025
Merged

osbuild: support more platforms; reduce memory usage for mkfs.erofs #4025

merged 15 commits into from
Feb 17, 2025

Conversation

dustymabe
Copy link
Member

See individual commit messages.

@dustymabe
cmd-compress: set default gzip compression level to 9
80e68dd 
It was originally set to 6 because that was the tool default
(5cbba45) but we have used level 9 in other places [1].

[1] https://github.com/coreos/coreos-assembler/blob/e1943d6adb8f0cb257630a76d02d0aa333261c70/src/cosalib/qemuvariants.py#L327
@dustymabe
osbuild: add patch for more options to qemu vmdk stage
e526a1b 
This will give us all the options we need to create a few of our
images that are VMDKs. osbuild/osbuild#2017
@dustymabe
osbuild: support building aliyun disks
c92e6e1
@dustymabe
osbuild: support building exoscale disks
5938792
@dustymabe
osbuild: support building openstack disks
eb4d341
@dustymabe
osbuild: support building vultr disks
098a2d4
@dustymabe
osbuild: support building aws disks
d9732db
@dustymabe
osbuild: support building digitalocean disks
9cb2a8a
@dustymabe
osbuild: support building ibmcloud disks
c55f5e7
@dustymabe
osbuild: support building azure disks
3d1cf20
@dustymabe
osbuild: support building azurestack disks
2eff2b4
@dustymabe
osbuild: support building nutanix disks
7703fed
@dustymabe
osbuild: add patch to set TMPDIR for mkfs.erofs
3c68ea1 
This will help reduce the memory requirements of mkfs.erofs.
osbuild/osbuild#2020
@dustymabe
cmdlib: bump default supermin VM memory request
cfabc2e 
Using mkfs.erofs has bumped the requirements for the amount of memory
we need here. While the memory usage was improved with the changes in
[1] and [2] we want to bump this here anyway to give ourselves some
wiggle room (especially because RHCOS is larger than FCOS).

[1] erofs/erofs-utils#13
[2] osbuild/osbuild#2020
@dustymabe
Copy link
Member Author

While I haven't tested each one of these directly I did verify the image files produced have the same attributes (using qemu-img info) and their sizes are roughly the same.

diff-build-sizes-after-cosa-compress.txt
diff-build-sizes-before-cosa-compress.txt
41.20250214.dev.3-qemu-img-infos.txt
41.20250214.dev.2-qemu-img-infos.txt

[dustymabe@media fcos]$ cat diff-build-sizes-after-cosa-compress.txt 
    platform     | compression  | 41.20250214.dev.2 | 41.20250214.dev.3
---------------------------------------------------------------------
ostree           | compressed   | 750MiB           | 750MiB
ostree           | uncompressed | N/A              | N/A   
oci-manifest     | compressed   | 15KiB            | 15KiB 
oci-manifest     | uncompressed | N/A              | N/A   
qemu             | compressed   | 699MiB           | 699MiB
qemu             | uncompressed | 1728MiB          | 1727MiB         
nutanix          | compressed   | 926MiB           | 930MiB
nutanix          | uncompressed | N/A              | N/A   
azurestack       | compressed   | 704MiB           | 726MiB
azurestack       | uncompressed | 10240MiB         | 10240MiB        
azure            | compressed   | 704MiB           | 726MiB
azure            | uncompressed | 10240MiB         | 10240MiB        
ibmcloud         | compressed   | 699MiB           | 722MiB
ibmcloud         | uncompressed | 1728MiB          | 1726MiB         
digitalocean     | compressed   | 868MiB           | 872MiB
digitalocean     | uncompressed | 1728MiB          | 1726MiB         
aws              | compressed   | 876MiB           | 879MiB
aws              | uncompressed | 898MiB           | 901MiB
vultr            | compressed   | 704MiB           | 726MiB
vultr            | uncompressed | 10240MiB         | 10240MiB        
openstack        | compressed   | 699MiB           | 722MiB
openstack        | uncompressed | 1728MiB          | 1726MiB         
exoscale         | compressed   | 699MiB           | 722MiB
exoscale         | uncompressed | 1728MiB          | 1726MiB         
aliyun           | compressed   | 699MiB           | 722MiB
aliyun           | uncompressed | 1728MiB          | 1726MiB         
gcp              | compressed   | 868MiB           | 872MiB
gcp              | uncompressed | 1722MiB          | N/A

I'm not exactly sure why the compressed version is about 22M larger than what we had before for the images that are just qcow2 transforms, but I'm not sure it's worth trying to chase it down either.

@dustymabe
Copy link
Member Author

ok. I think this is going to require us to bump our cache qcow size. I did a rawhide run and we barely made it through:

[2025-02-14T20:31:01.724Z] Filesystem      Size  Used Avail Use% Mounted on
[2025-02-14T20:31:01.724Z] /dev/vdb1        30G   30G  815M  98% /home/jenkins/agent/workspace/build/cache

The RHCOS one I kicked off did fail.

@dustymabe
cmdlib: bump cache qcow2 size
38189f6 
Now that we can build more and more artifacts in OSBuild it increases
the size we need for the cache qcow that gets attached to the supermin
VM. Let's bump to 40G here.

Observing a RHCOS and FCOS run here they both use right around 30G today
because FCOS builds for more platforms, but RHCOS has a bigger payload,
so they even out. In the they will be even bigger when we become able to
build the last few artifacts (vmware, virtualbox, etc) using OSBuild.
@dustymabe
Copy link
Member Author

I think this is going to require us to bump our cache qcow size.

added a commit here to do just that.

nikita-dubrovskii
nikita-dubrovskii reviewed Feb 17, 2025
View reviewed changes
Copy link
Contributor

@nikita-dubrovskii nikita-dubrovskii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Mostly all new platform.NAME.ipp.yaml look the same, does it make sense to make them auto-generated, or as symlink to 1 base-config + some env variable for plathform-name ?

@dustymabe
Copy link
Member Author

LGTM.

Mostly all new platform.NAME.ipp.yaml look the same, does it make sense to make them auto-generated, or as symlink to 1 base-config + some env variable for plathform-name ?

Possibly. I've thought about it a little bit. Autogenerated would be more likely to be compatible with OSBuild.

@dustymabe
Copy link
Member Author

While I haven't tested each one of these directly

Just wanted to mention that I did a test rawhide run with these changes and our cloud tests (AWS, Azure, GCP, OpenStack) did pass, so at least we know those images are still functioning.

@dustymabe dustymabe merged commit 22aca49 into coreos:main Feb 17, 2025
5 checks passed
@dustymabe dustymabe deleted the dusty-cloud-osbuild branch February 17, 2025 13:42
This was referenced Feb 18, 2025
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nikita-dubrovskii nikita-dubrovskii nikita-dubrovskii approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dustymabe @nikita-dubrovskii