On Fri, Sep 16, 2016 at 7:02 AM, Colin Walters <walters@xxxxxxxxxx> 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/server@xxxxxxxxxxxxxxxxxxxxxxx/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/server@xxxxxxxxxxxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
