On Fri, Sep 16, 2016 at 7:02 AM, Colin Walters <walt...@verbum.org> wrote:
>
>
> On Thu, Sep 15, 2016, at 09:57 AM, Dusty Mabe wrote:
>
>> That is correct, but changing a default like that might be a bad idea.
>> My opinion is that it should happen on a major release boundary.
>
> One thing this impacts is the AH partitioning - it no longer makes
> sense by default with overlayfs.  I think we should probably do exactly
> the same thing as the Server SIG (and consider doing it for Workstation
> too), which actually argues for just fixing the Anaconda defaults.
>
> Server thread:
> https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/D7ZK7SILYDYAATRFS6BFWZQWS6KSRGDG/

The genesis of that was me pointing to Cloud Atomic ISO's handling;
since Server went with pretty much the identical layout, it managed to
get slipped in for Alpha. It was a proven layout. [1]

For an Atomic Host overlayfs based layout, there's nothing within
Fedora that's a proven layout. For starters, it could be something
much simpler than what CoreOS is doing [2]. If the target installation
is VM, then dropping LVM stuff makes sense. If it's going to include
baremetal, keeping LVM makes sense. I'm a bit unclear on this point,
but with a handwave it sorta feels like Cloud->Container WG is far
less interested in the baremetal case, where Server is about as
interested in baremetal as VM and container cases. If that's true,
then the CoreOS layout is a decent starting point, and just needs some
simplification to account for ostree deployments rather than partition
priority flipping.

Inode exhaustion?

If the installer is going to create the file system used for overlayfs
backing storage with ext4, that probably means mkfs.ext4 -i 4096 will
need to be used; so how does that get propagated to only AH installs,
for both automatic and custom partitioning? Or figure out a way to
drop custom/manual partitioning from the UI. Or does using XFS
mitigate this issue? A simple search turns up no inode exhaustion
reports with XFS. The work around for ext4 is at mkfs time, it's not
something that can be changed later.

Release blocking and custom partitioning?

Upon AH image becoming release blocking, then "The installer must be
able to create and install to any workable partition layout using any
file system and/or container format combination offered in a default
installer configuration. " applies. Example bug [3] where this fails
right now. Does it make sense for AH installations to somehow be
exempt from custom partitioning resulting in successful installations?
And what would that look like criterion wise (just grant an
exception?) or installer wise (drop the custom UI or put up warnings
upon entering?)



[1]
https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/PLWNOM6Z5226VZYUHTL6KMS3553VSQ3W/

[2]
https://coreos.com/os/docs/latest/sdk-disk-partitions.html
Trivial pursuit is this "the GPT priority attribute" which I can find
no where else, but I rather like this idea of using an xattr on a
directory as the hint for which fs tree the bootloader should use
rather than writing out new bootloader configurations.

[3]
https://bugzilla.redhat.com/show_bug.cgi?id=1289752




-- 
Chris Murphy
_______________________________________________
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Reply via email to