[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rhel 5.4 patch (#462615)

Jeremy Katz wrote:
On Tuesday, May 12 2009, Radek Vykydal said:
Introduces new kickstart option "clearpart --scrublvm".
Consists of 2 parts - patch of anaconda and pykickstart.
The approach is described in anaconda patch.
I tested it with and without --initlabel, and --drives
options and also in combination with ignoredisk ks command.
If you don't like name of the option, I am eager to use

Two things --

1) We really shouldn't add options in RHEL releases before they're
available in Fedora.  Every time we've done so has ended up being kind
of problematic with customers coming to depend on and really really care
about the option (... even if it later becomes irrelevant :-)

2) Why make it an explicit option?  Instead if it's something that's
needed, let's just do it and then the user doesn't have to worry about
doing it vs not.
I agree with both points. There is probably no much sense in
using clearpart without --scrublvm option, but
with the proposed implementation, there is one slight difference
in behavior of clearpart with/without --scrublvm option:

Supposing we install on disk with existing LVs,

- If we use clearpart --scrublvm without partitioning in ks:
lvm metadata will have been already wiped out in UI partitioning step
so if we choose "Create custom layout" we won't have VGs and LVs of
scrubbed PVs in partition editor.

- If we use clearpart without partitioning in ks:
choosing "Create custom layout" in UI partitioning step
effectively means ignoring the clearpart command, so we can
edit existing LVs in UI.

I tried also alternative implementation where PVs are cleared
in clearpart action (in a partition delete request), but
with that approach it is impossible to clear lvm metadata if
--initlabel is used.

With your points in mind, I am in doubts whether the bug should have been acked.

One case (a very corner-one) I know about where we aren't able to handle
preexisting lvm metadata with our patches added into 5.3,
and where the scrublvm patch seems as viable solution
is the one in https://bugzilla.redhat.com/show_bug.cgi?id=476582
(installing on multiple disks with duplicate VG names)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]