[PATCH] Remove all dependent devices of san device becoming multipath (#1058939)

Radek Vykydal rvykydal at redhat.com
Fri Jan 31 11:00:08 UTC 2014


On 01/30/2014 04:53 PM, David Lehman wrote:
> On Thu, 2014-01-30 at 11:27 +0100, Radek Vykydal wrote:
>> Also change the format to multipath after the devices are removed,
>> not before.
>> This should fix also bug #1058681.
> On master I already have a patch in my working tree to move
> Blivet.recursiveRemove into DeviceTree. It's not an invasive change, and
> would save you from duplicating most of that method's code here. Feel
> free to do that as part of your fix for this bug.
>

Yes, I was looking at the recursiveRemove, but in my patch I don't want to
actually remove (destroy) the children of the device (the device becoming a
mpath member), I only want to remove them from device tree so that we 
have the
tree similar to one we would get if the device was detected/added to the 
tree
as mpath member already during the first populate (or after storage reset).


>> I am starting to wonder whether we can really manage populate after adding
>> new san device (iSCSI, FCoE, zFCP) in GUI making a device already in tree
>> multipath member - without resetting storage.
> You'll probably also need to consider the possibility that there are
> actions already scheduled using the individual device before it was made
> into a multipath member.

That is something beyond my ambitions :) I just want to make basic scenario
- first add sans and choose disks, then do partitioning - work. Assuming 
that
user has to wait for devices to appear before doing partitioning. And to
refresh the devices list eventually - as would be the case with FCoE 
where if
the settle timeout after adding FCoE is too short and devices don't appear
before populate is called, user has to try to add the FCoE SAN again to 
trigger
another populate. (I have a request and trivial patch adding [Refresh] 
button
to the filter GUI for this case.) This case should be probably handled 
using
events and if we make it asynchronous (which probably only makes sense since
we can't know no more FCoE device would appear) then we'll need to 
handle the
possibility you mention above. But it is another level then my attempt 
of hacking
mpath san issues around.



More information about the anaconda-patches mailing list