[blivet:rhel7/master 3/3] Set up Blivet.resizeDevice() to handle LUKS devices (#1076055)
amulhern at redhat.com
Wed Sep 24 19:16:39 UTC 2014
----- Original Message -----
> From: "David Lehman" <dlehman at redhat.com>
> To: anaconda-patches at lists.fedorahosted.org
> Sent: Wednesday, September 24, 2014 12:21:53 PM
> Subject: Re: [blivet:rhel7/master 3/3] Set up Blivet.resizeDevice() to handle LUKS devices (#1076055)
> On 09/24/2014 11:12 AM, mulhern wrote:
> > Previously, resizeDevice() could not resize a LUKS device.
> > A LUKS device is just a kind of veneer over its slave device and is the
> > only kind of devices such that device.raw_device is not device.
> > blivet does not currently implement a resize() method for LUKSDevice and in
> > the general case, it is always necessary to resize the raw_device in order
> > to resize the LUKSDevice itself. However, when blivet is able to resize the
> > LUKS Device, which at this point is exactly when the LUKSDevice does not
> > yet exist and its raw_device is resizable, resizeDevice() should be able to
> > do it.
> Why not just be more careful in anaconda which device you pass to
> resizeDevice? This all seems like dangerous blurring of lines in blivet
> to avoid a few LOC in anaconda. I don't object to adding comments or
> checks, but making arrangements to allow calling resizeDevice on a
> non-existing device seems like the wrong way to go. I think this was my
> basic issue with the last set you posted for this bug.
I think it's the existence of a LUKSDevice that has muddied the waters.
For this particular problem, it would be easier if we had represented an
encryption of a device in some other way.
My feeling is that, since resizeDevice() is a high-level method, and
blivet has other users than anaconda, it should
generate the appropriate set of actions required to resize any device
that it can manage this task for.
Since a LUKSDevice is a Device, that ought to include LUKSDevices.
The basic problem, as I understood it, with my previous solution,
was that it generated a ResizeAction()
for a non-resizable device, which it no longer does.
Alas, anaconda patch set already has plenty of LOC in it and will
probably develop more now that the issue with on_device_type_changed()
is looking so problematic.
One thing that I think it is wrong to do, is to decide,
in anaconda, how much extra space the slave device needs, more
than the size the user specified, in order to make the LUKS device
end up the size the user specified. That should be decided in blivet
and that's another reason why I like this change to resizeDevice().
However, if you're happy to make the slave device the size that user specified
for the LUKS device, then I can withdraw patch (3) in this set,
and just call resizeDevice() on use_dev, instead of on device.
in anaconda patch 5. But that difference may be visible to the user
in 2 decimal places of precision, i.e., they specify 12 GiB for the
LUKS device and only get 11.99 GiB displayed.
More information about the anaconda-patches