[Libguestfs] [PATCH] New API: mdadm-stop for stopping MD devices.

[Wanlong Gao]

On 11/24/2011 01:17 AM, Matthew Booth wrote:

> On 23/11/11 17:11, Matthew Booth wrote:
>> On 23/11/11 16:22, Richard W.M. Jones wrote:
>>> On Wed, Nov 23, 2011 at 03:02:19PM +0000, Matthew Booth wrote:
>>>> On 23/11/11 14:43, Wanlong Gao wrote:
>>>>> This API is used to stop a md device.
>>>>> When we want to move a device to another md array, we should
>>>>> stop the md device which contained this device first.
>>>>
>>>> I'm not convinced we should extend the md api in libguestfs to
>>>> active manipulation. I wasn't convinced that mdadm-create was
>>>> worthwhile either, but it made a test case ever so slightly tidier.
>>>> To me, MD devices are the domain of physical machines. We need to be
>>>> able to *read* them (for P2V apart from anything else), but I think
>>>> manipulation is opening an unnecessary can of worms.
>>>
>>> But is there any penalty to carrying this?
>>
>> I can think of 2:
>>
>> 1. Maintenance: I know you think this is free, but some day mdadm --stop
>> might change behaviour, and then the api will break.
>>
>> 2. A false sense of expectation: Having an incomplete md api can only
>> lead to frustration. Implementing a complete md api would require a
>> large amount of effort for something which we don't have a convincing
>> use case for (i.e. nobody's ever going to use it anyway).
> 
> There's another good one, actually: Testing. mdadm-create has already 
> created a testing problem, because test-mdadm.sh fails mysteriously on 
> my machine, but didn't before and doesn't for you or Wanlong. Especially 


Yeah, we need more test and fix before this go to stable.

> for something like MD, which has a complex subsystem underlying it which 
> we don't fully understand in our team, adding and adequately testing a 
> new API is an expensive operation.


It's not a thing, we can support the simple ones which allow users at least
creating and stopping the md. IMO, the basic function is needed.

Thanks
-Wanlong Gao

> 
> Matt