On Fri, Mar 11, 2016 at 7:05 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
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've asked over on cloud@ where the code is. The kickstart just says
use autopartitioning, I see no breakdown. It seems logical the cloud
productized installer behaves differently.
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:
Entirely up to the WG what the time frame is. The code to alter the
installer behavior exists, is tested, and works. So it seems like a
safe change you could do for Fedora 24.
A possible gotcha for Server is if the user installs Docker,
docker-storage-setup is installed and its systemd unit enabled. I
don't know if it immediately starts also, or only at next boot. But
upon running, all free extents in the VG are made into a dm thin pool.
I was imprecise when I wrote "On first boot, docker-storage-setup
turns those free extents into a thin pool LV." That implies it's an
LVM managed thin pool, which it isn't. It's only manageable by
dmsetup. This suggests some special handing for Server perhaps. Anyway
I found it really non-obvious when suddenly a bunch of free space was
gone and I couldn't manage it with LVM tools.
> 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).
Yeah oops. I use Fedora 23 Server and cockpit myself, cockpit is badass.
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.
Create, grow, destroy LVs (and filesystems on them) for sure.
Optionally assign mount point. I haven't looked to see if storaged
understands dm thin pools (as opposed to LVM thin pools).
--
Chris Murphy