install: Add "extra" space

[cgwalters]

Today, bootc install to-disk has --root-size. But that's not in the install config. I think we should delete --root-size, moving this to the install config.

Add min and max "constraints"

For generic base images, we can't sanely provide a default size because the user may add an arbitrary amount of data. So the first idea here is that we support base images providing an "elastic" default that takes as input the base image size. Something like this:

[install.filesystem.root]
size-constraints-min = "double-image,extra=2Gi"

Where size-constraints-min is a comma separated list of "constraints". double-image here means that we allocate space at least for 2x the container image size (for inplace upgrades), and extra=2Gi of free space on top of that.

For "final" images derived by the end consumer, they can do e.g.

[install.filesystem.root]
size-max = "10Gi"

if they want to have a fixed size that they know exactly. (Do we error out if size-constraints-min would be greater than size-max, or just ignore it? Note at least they can always just RUN rm /usr/lib/bootc/install/* if they want to fully take ownership)

[cgwalters]

Prep PR in https://github.com/containers/bootc/pull/289

[travier]

Add "extra" space

One thing that came up is the idea that the container should be able to define a default "rootfs" size. However what I think would work better is a model where the container can specify extra space beyond the container image size. Something like this:

[install.rootfs]
extra = "5G"

This way, someone deriving from a base image (and adding e.g. 2 gigs of extra content) would automatically have the rootfs expand, and still have 5G of extra space.

This also mean that each installation has potentially a different size for the rootfs, depending on the size of the container at the installation time. Not great for reproducibility/predictability.

[cgwalters]

On Tue, Jan 30, 2024, at 3:47 AM, Timothée Ravier wrote:

This also mean that each installation as potentially a different size for the rootfs, depending on the size of the container at the installation time. Not great for reproducibility/predictability.

This is a potential default for generic base images. If all we supported was a generic “the size is 10gb by default “ then what happens is the disk size is “predictable”, but the free space isn’t and would trend towards zero.

For anyone making a “final” derived image, they can override this to specify whatever sizes and partitioning in general they want, right?

But as far as defaults this seems like the least bad.

Hmm though maybe we should have something that defaults to double the image size plus extra, to ensure in place upgrades work by default.

[travier]

Hmm though maybe we should have something that defaults to double the image size plus extra, to ensure in place upgrades work by default.

This is potentially a better default indeed if we prefer being dynamic.

[cgwalters]

I've updated the initial comment here with a more fleshed out proposal.

[cgwalters]

@ondrejbudai WDYT?

[achilleas-k]

[install.filesystem.root]
size-constraints-min = "double-image,extra=2Gi"

I like the idea here of specifically referring to the base size, though not sure about the format and naming. Could be cleaner to break it down further?

[install.filesystem.root]
min-size = "double-image"
extra-space = "2Gi"

(not too fond of that format either).

Could introduce some preset variable names instead:

min-size = "{{imagesize}}*2 + 2 Gi"

but now it feels like we're inventing a whole language for it.

[cgwalters]

[install.filesystem.root]
min-size = "double-image"
extra-space = "2Gi"

In this one, is min-size just a single value? What other values could it take (beyond "" as "no minimum"). Are we leaving space for e.g. triple-image in the future?

min-size = "{{imagesize}}*2 + 2 Gi"

Yeah...would hope to not need an expression language for this. It is in some ways the most obvious thing to do, and probably not hard, but feels less declarative. That said, not opposed either if folks feel strongly.

Looking at repart.d relevant prior art looks like the Weight value alongside the obvious SizeMinBytes and SizeMaxBytes.

But, repart is pretty designed for "fixed" inputs in general apart from CopyFiles...and I think we do want to just special case this "container image input size".

Here's another idea syntax proposal:

size-min = "image-multiple=2"
size-extra = "2Gi"

This would also support size-min = "image-multiple=3" etc. Also changed to more consistently prefix size-related things with size-.

[achilleas-k]

Yeah...would hope to not need an expression language for this. It is in some ways the most obvious thing to do, and probably not hard, but feels less declarative.

Agreed.

Here's another idea syntax proposal:

size-min = "image-multiple=2"
size-extra = "2Gi"

This would also support size-min = "image-multiple=3" etc. Also changed to more consistently prefix size-related things with size-.

I like this!