On 03/10/2016 11:19 PM, Chris Murphy wrote:
Most Server product users probably use custom storage configurations
in the installer. But that might be a wrong guess.
This is the default auto partitioning for a 2TB drive in Server:
https://drive.google.com/open?id=0B_2Asp8DGjJ9b0ViMUpPZkFoTW8
/home is obviously quite huge, and is optimal for something like a
file server. It's suboptimal for VM's, databases, and containers.
While a Btrfs layout (I can't help myself) solves the unknown space
and use case question without involving the user, there are perhaps
other suboptimals.
Yeah, btrfs is Not Gonna Happen in the immediate future. Sorry.
But Cloud Atomic ISO offers a solution. Its autopartitioning layout
reserves a large pile of free extents in the VG, not associating them
with any LV. On first boot, docker-storage-setup turns those free
extents into a thin pool LV. But the Server product could just leave
them unallocated, and the user could allocate that space however they
want post-install.
This is actually a really good idea. We need to look into whether we can
actually do it, though. Right now, the autopart is handled by Anaconda itself
and is pretty much common to all of the Editions that use it for installation.
However, Anaconda has an extensible InstallClass that we already use in Server
(that's how we get the XFS default filesystem instead of ext4).
We could look to see if it allows extending the autopart definition (I suspect
it probably does), but this is likely to be a non-trivial engineering effort.
I'm not certain I'm comfortable doing this after Alpha Freeze for F24, but we
could start planning it for F25 right away. That would also give us time to
address the stuff below:
Documentation could suggest system-storage-manger or blivet-gui as
alternatives to LVM tools for allocating that space.
Well, ssm is of course a very useful CLI for setting up storage. For a GUI, I
don't think blivet-gui makes sense, as Server doesn't ship with a graphical
environment by default.
On the other hand, the Cockpit admin console (which we do ship with by default)
has a fairly impressive storage management capability powered by the storaged
API (which in turn uses a variety of low-level features, ssm among them IIRC).
So if we decide to go this route (and I like the idea quite a lot), I think our
best move would be to focus on figuring out exactly what use-cases we want to
solve and then making sure that the user experience in Cockpit solves them
neatly and discoverably.
Comments?