progress: set --cache-max-size in osbuild

[mvo5]

[draft as this needs https://github.com//pull/811 so that we have a single way to run osbuild plus can actually control its options (which images:osbuild cannot currently]

This commit allows controlling the osbuild --cache-max-size
option. By default it will set the cache to 20GiB but allows
this to be controlled by the user.

Thanks to Simon for raising this.

[supakeen]

Happy about this; a quick note on the size. A single Fedora Minimal build takes up about 10 GiB of space so 20 GiB is indeed a decent minimum.

Note also that due to how we setup pipelines right now basically no output gets cached (at least in in the image-builder-case, I didn't verify the bootc-image-builder case yet).

[achilleas-k]

Without checkpoints, osbuild will only cache sources.

[achilleas-k]

I didn't verify the bootc-image-builder case yet

bootc-image-builder/bib/pkg/progress/progress.go

Line 332 in 9270d2e

_, err := osbuild.RunOSBuild(manifest, store, outputDirectory, exports, nil, extraEnv, false, os.Stderr)

No checkpoints there.

Actually, we never set any checkpoints in osbuild-composer or bootc-image-builder (so far).

[supakeen]

I didn't verify the bootc-image-builder case yet

bootc-image-builder/bib/pkg/progress/progress.go

Line 332 in 9270d2e

_, err := osbuild.RunOSBuild(manifest, store, outputDirectory, exports, nil, extraEnv, false, os.Stderr)

No checkpoints there.

Actually, we never set any checkpoints in osbuild-composer or bootc-image-builder (so far).

It would be 'OK' to pass --checkpoint="*", something we implemented a while back I think. However; as I've said previously as well with the current way we generate pipelines nothing will actually get cached post the buildroot even when passing checkpoints.

Perhaps it'd be fine to then only pass --checkpoint="buildroot" for things that are generated by images?

[achilleas-k]

with the current way we generate pipelines nothing will actually get cached post the buildroot even when passing checkpoints.

Why wouldn't they be cached? Do you mean because our build pipeline is dynamic it wont be reused or that it actually wont be cached?

Even with dynamic build packages, there are a lot of cases where a different build wont affect the build packages. Rebuilding the same image type (or a very similar one) with a different blueprint, depending on customizations, might or might not affect build packages. Introducing customizations often adds a package, but changing values might not. Neither does adding a blueprint package.

Going back to a fat build root isn't impossible or out of the question though. The reason we never had checkpoints in osbuild-composer and the service so far was lack of cleanup, which @mvo5 added a while ago.

[supakeen]

with the current way we generate pipelines nothing will actually get cached post the buildroot even when passing checkpoints.

Why wouldn't they be cached? Do you mean because our build pipeline is dynamic it wont be reused or that it actually wont be cached?

Even with dynamic build packages, there are a lot of cases where a different build wont affect the build packages. Rebuilding the same image type (or a very similar one) with a different blueprint, depending on customizations, might or might not affect build packages. Introducing customizations often adds a package, but changing values might not. Neither does adding a blueprint package.

Going back to a fat build root isn't impossible or out of the question though. The reason we never had checkpoints in osbuild-composer and the service so far was lack of cleanup, which @mvo5 added a while ago.

The build pipeline can be cached as long as it's the same one twice (or multiple can be in the cache). However, the os pipeline contains UUIDs which are different for every build invalidating it, and all pipelines dependent on it.

[achilleas-k]

The build pipeline can be cached as long as it's the same one twice (or multiple can be in the cache). However, the os pipeline contains UUIDs which are different for every build invalidating it, and all pipelines dependent on it.

aaah of course. Yes, sorry for the nonsense then. I was just focused on the build pipeline.