bib: add --filesystems commandline option for basic customizations

[mvo5]

[draft so that we can discuss the stawman commandline that is inspired by Dans (thanks!) suggestion]

This commit adds support for basic filesystem customization. The main use-case right now is to allow to create a bigger default rootfs. This can be done via:

$ bootc-image-builder --filesystems "/:20G"

This is conceptually very similar to PR#124 but instead of blueprints it is purely commandline driven. The rational is that it's unclear what customization format we eventually want to support but it is clear that we need a way to drive this from the commandline.

The format is designed to be extensible to a certain extend, so

bib --filesystems "/:20G,/var:100G:xfs"

is currently a strawman for supporting more customizations in the future.

This PR is limited to "/" because we currently have no way to inject /etc/fstab or systemd-mount units (the bootc --copy-etc PR will probably helper here in the future).

[cgwalters]

This PR is limited to "/" because we currently have no way to inject /etc/fstab or systemd-mount units (the bootc --copy-etc PR will probably helper here in the future).

To be clear though again, it's definitely supported to just write into the deployment root's /etc (and /var, though that one in the general case can require mounting that explicitly).

[cgwalters]

Hmm. Having this as a string seems not future proof to me (I know it gets a lot into what format we present but...)

I think I would propose that we:

• Default the disk image size based on the container image per discussions in install: Add "extra" space containers/bootc#287 (ignoring having the container control the sizing to start) i.e. we double the input container size, with our existing hardcoded 10G becoming a minimum
• Add a single simple CLI flag like --add-root-size 100G or so that expands the root filesystem only

[mvo5]

This PR is limited to "/" because we currently have no way to inject /etc/fstab or systemd-mount units (the bootc --copy-etc PR will probably helper here in the future).

To be clear though again, it's definitely supported to just write into the deployment root's /etc (and /var, though that one in the general case can require mounting that explicitly).

Really sorry, I should have phrased this slightly differently maybe. What I mean is that I still have not figured out how to do it exactly but I also have not sat down and tried it.

[mvo5]

Hmm. Having this as a string seems not future proof to me (I know it gets a lot into what format we present but...)

I think I would propose that we:

* Default the disk image size based on the container image per discussions in [install: Add "extra" space containers/bootc#287](https://github.com/containers/bootc/issues/287) (ignoring having the container control the sizing to start) i.e. we double the input container size, with our existing hardcoded 10G becoming a minimum

* Add a single simple CLI flag like `--add-root-size 100G` or so that expands the root filesystem only

Thanks for the suggesiton - I will definitely fix the missing default based on size. On the second point: during the meeting Dan suggested to try to come up with something more extensible, this is why I went with "--filesystems" in the current from. But maybe --fssize 10G and if we decide to go with more options it could be --fssize /var:10G and if no path is given we assume "/" etc. Would something like this be an acceptable compromise?

[cgwalters]

We should definitely create an overall plan here around extensibility but my instinct here is we're going to hit complexity limits on a CLI interface and will end up with a config file type approach.

[ondrejbudai]

Me, @mvo5 and @achilleas-k agreed on implementing the first part of the Colin's comment:

Default the disk image size based on the container image per discussions in containers/bootc#287 (ignoring having the container control the sizing to start) i.e. we double the input container size, with our existing hardcoded 10G becoming a minimum

This will help all users that are trying to create disk images from huge container images, which seems like a quick, and non-controversial win.

It would be surely great to have more fine-grained control, so let's do it as a followup when we have a plan where to store the partitioning config (inside the container image, or passed via bib's CLI, or both) and which format we should use (see #124 vs. containers/bootc#289).

[mvo5]

Based on the discussion in #283 (comment) I will close this one and started the new approach in #291