Filesystem type customization

[croissanne]

This pull request includes:

• [ ] adequate testing for the new functionality or fixed issue
• [ ] adequate documentation informing people about the change such as
  • [ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

[croissanne]

I'm not sure if this PR actually makes sense for fedora. Like lvm + btrfs really doesn't make any sense. But unsure what to do here.

In out of thread discussion with @achilleas-k, maybe on fedora we should do or btrfs only; or lvm + xfs or ext4 (or just plain ext4 or xfs).

[achilleas-k]

I'm not sure if this PR actually makes sense for fedora. Like lvm + btrfs really doesn't make any sense. But unsure what to do here.

In out of thread discussion with @achilleas-k, maybe on fedora we should do or btrfs only; or lvm + xfs or ext4 (or just plain ext4 or xfs).

Incoming braindump (this might get rambly): What if we only allowed selecting one, global filesystem type for all customisations? That way we could limit users to the following options:

• btrfs
• ext4
• xfs
• lvm-ext4
• lvm-xfs

Alternatively, we could do what we always did and always make it lvm when customized and it's not btrfs (i.e., when the user selects ext4 or xfs), but let the user select xfs or ext4 for the partitions inside the lvm container. There's another version of this where we add two global options, fscontainer type (btrfs|lvm) and if it's lvm a second option lets the user select fs type (ext4|xfs), but now it's getting too complicated.

For context the current situation is that, when any kind of customization is made, the partition layout becomes lvm-xfs. ext4 is only used when it's the default for a distro and it's not customized. btrfs is never available, we just have internal code support for it.

[teg]

Could we please have a summary in the PR description? :)

Am I right in my understanding that this PR allows the fs type to be set for any customised partition? I did not see any restrictions to what types are allowed, but maybe I read too quickly? Should we have "supported fstypes" per distro in the same way we now have default per distro?

We should make sure that we restrict the selections in such a way that we end up with the right tools installed to build the image, but also work with the filesystems at runtime (not strictly necessary, but that's how it was so far, so I assume we should continue that logic until we decide otherwise).

I think for fedora this is handled by the new abstractions (as long as the fstypes are supported at all), but for RHEL we might need to review each image definitions to see what we support.

[teg]

Regarding the API:

The logic now (for better or worse) is that the customisations are not exhaustive, we just figure out the best way to satisfy the requests by adding whatever else we think makes the most sense. Hence if you have more than one partition we'll add LVM. Explicitly adding LVM is therefore not supported (but totally could be in the future).

I think we should consider following the same logic, and still keep the customisations per filesystem, and then we'd select the global choices based on that.

Something like:

• You can request filesystem type on each filesystem - and these will be respected
• You cannot combine btrfs with non-btrfs
• You can only select filesyestms supported by the given distro.
• If a btrfs filesystem is requested, we make everything btrfs - no LVM
• If a non-btrfs filesystem is requested, we make sure nothing is on btrfs - even if that is the default for the distro
• If there is more than one filestyem defined (and we are not on btrfs), we put it on LVM

In the future we could still extend this to allow configuring containers in more detail, naming volume groups etc.

[teg]

If I may contradict myself, I do like @achilleas-k suggestion of having the layout be a global option as described (less surprising and fewer combinations to test). My only reservation is how would this look if and when we decide to make the customisation more fine-grained, would it be easily extensible? I guess, worst case we could say the global option should be left unset if a future more fine-grained configuration mechanism is used.

[croissanne]

Could we please have a summary in the PR description? :) of course

---

The current state is that btrfs is actually not supported, btrfs floats around a bit in the code here and there but the fedora distro definition isn't able to actually build it. We discussed this PR a bit and the best option seems to just panic on btrfs for now. The main goal is to just allow lvm + ext4 or xfs, anything else wouldn't work anyway.

I think we should consider following the same logic, and still keep the customisations per filesystem, and then we'd select the global choices based on that. ... In the future we could still extend this to allow configuring containers in more detail, naming volume groups etc.

Having a global section (or at least the ability to define an overall mountpoint grouping scheme), does facilitate setting options like the volume group name. I don't think having to set the name on each mountpoint, and then infer whatever we can from it, is intuitive. Regardless I don't think this PR should do that, as the goal isn't to mix physical/btrfs/lvm at all here.

If I may contradict myself, I do like @achilleas-k suggestion of having the layout be a global option as described (less surprising and fewer combinations to test). My only reservation is how would this look if and when we decide to make the customisation more fine-grained, would it be easily extensible? I guess, worst case we could say the global option should be left unset if a future more fine-grained configuration mechanism is used.

I don't think we lock ourselves in too badly. If we really want to support multiple lvm groups or whatever, we just accept multiple 'global' options and the ability to attach each mountpoint to one of the groups? But I'm not sure if we actually want to do this, mixing schemes seems like a validation/support nightmare.