-
Notifications
You must be signed in to change notification settings - Fork 70
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.
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
install: Add "extra" space #287
Comments
Keep (but soft-deprecate) the existing `root-fs-type`, and add a more general set of tables in `install.filesystem.root`, with `type` as a field underneath that. This somewhat resembles the [Image Builder blueprint](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-system-images-with-composer-command-line-interface_composing-a-customized-rhel-system-image#composer-blueprint-format_creating-system-images-with-composer-command-line-interface) design. In particular, this aims to leave space for containers#287 where we'd add e.g. ``` [install.filesystem.root] extra = "5G" ``` for size specification. Another obvious extension would be `options` to pass through options to `mkfs.$fs`; not clear to me we totally want to go there, but we clearly need something a bit more general. Signed-off-by: Colin Walters <walters@verbum.org>
Prep PR in #289 |
Keep (but soft-deprecate) the existing `root-fs-type`, and add a more general set of tables in `install.filesystem.root`, with `type` as a field underneath that. This somewhat resembles the [Image Builder blueprint](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-system-images-with-composer-command-line-interface_composing-a-customized-rhel-system-image#composer-blueprint-format_creating-system-images-with-composer-command-line-interface) design. In particular, this aims to leave space for containers#287 where we'd add e.g. ``` [install.filesystem.root] extra = "5G" ``` for size specification. Another obvious extension would be `options` to pass through options to `mkfs.$fs`; not clear to me we totally want to go there, but we clearly need something a bit more general. Signed-off-by: Colin Walters <walters@verbum.org>
Keep (but soft-deprecate) the existing `root-fs-type`, and add a more general set of tables in `install.filesystem.root`, with `type` as a field underneath that. This somewhat resembles the [Image Builder blueprint](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-system-images-with-composer-command-line-interface_composing-a-customized-rhel-system-image#composer-blueprint-format_creating-system-images-with-composer-command-line-interface) design. In particular, this aims to leave space for containers#287 where we'd add e.g. ``` [install.filesystem.root] extra = "5G" ``` for size specification. Another obvious extension would be `options` to pass through options to `mkfs.$fs`; not clear to me we totally want to go there, but we clearly need something a bit more general. Signed-off-by: Colin Walters <walters@verbum.org>
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. |
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.
|
This is potentially a better default indeed if we prefer being dynamic. |
I've updated the initial comment here with a more fleshed out proposal. |
@ondrejbudai WDYT? |
I like the idea here of specifically referring to the base size, though not sure about the format and naming.
(not too fond of that format either). Could introduce some preset variable names instead:
but now it feels like we're inventing a whole language for it. |
In this one, is
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 But, repart is pretty designed for "fixed" inputs in general apart from Here's another idea syntax proposal:
This would also support |
Agreed.
I like this! |
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:
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), andextra=2Gi
of free space on top of that.For "final" images derived by the end consumer, they can do e.g.
if they want to have a fixed size that they know exactly. (Do we error out if
size-constraints-min
would be greater thansize-max
, or just ignore it? Note at least they can always justRUN rm /usr/lib/bootc/install/*
if they want to fully take ownership)The text was updated successfully, but these errors were encountered: