[Engine-devel] getDeviceList should report partitioned devices, too

[Livnat Peer]

On 22/01/12 10:05, Eduardo Warszawski wrote:
> 
> 
> ----- Original Message -----
>> On 22/01/12 09:39, Eduardo Warszawski wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> On 22/01/12 08:28, Eduardo Warszawski wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> On Wed, Jan 18, 2012 at 06:17:53AM -0500, Ayal Baron wrote:
>>>>>>>> Can we broaden the scope and also allow passing createVG
>>>>>>>> partitioned devices with an override flag or something? (we'd
>>>>>>>> need
>>>>>>>> to check the devices and run "kpartx -d" and fdisk to clean
>>>>>>>> the
>>>>>>>> devices before calling pvcreate).
>>>>>>>
>>>>>>> We can, and we should. My initial patch is just the bare
>>>>>>> minimum;
>>>>>>> I'd
>>>>>>> like
>>>>>>> Douglas to carry it on, and I am still waiting to meet his
>>>>>>> Engine
>>>>>>> counterpart.
>>>>>>> Currently, a LUN that was once used as a raw hard disk cannot
>>>>>>> be
>>>>>>> used
>>>>>>> by RHEV;
>>>>>>> that's sad.
>>>>>>>
>>>>>>> How about this for API:
>>>>>>>
>>>>>>>    createVG(self, vgname, devlist, options={trashpart_devlist:
>>>>>>>    []})
>>>>>>
>>>>>> No, stop using options as a trash can.
>>>>>> If we're changing the API, it should already be just passing a
>>>>>> LUNs
>>>>>> dictionary to createStorageDomain and start deprecating createVG
>>>>>
>>>>> Was agreed that createVG and all vg-uuid aware functions will be
>>>>> removed shortly.
>>>>> Use only createStorageDomain.
>>>>>
>>>>
>>>> When you write 'removed'? you don't actually mean remove, right?
>>> Yes, I do.
>>> The flows are simpler from the RHEV-M and VDSM sides.
>>
>> I agree.
>>
>>> VG's can be created, removed, etc. using lvm tools.
>>> VDSM is only about Storage Domains and not a VG manager.
>>
>> I agree
>>
>>> What's the point of creating a VG using VDSM if not for building a
>>> SD?
>>
>> Backwards compatibility.
> For backwards compatibility we don't need to develop further the createVG interface.
> If the API is changed createStorageDomain should receive the device dict 
> (as Ayal said), and then we can mockup the createVG part, as we already do with the 
> formatStorageDomain-removeVG functions.

I don't expect you to further develop the createVG verb only not to
remove it.
In addition you should take into consideration that the engine is going
to keep using the current createVG flow, not because we like it simply
because making the change for running another flow is not prioritized
ATM, so please make sure everything is working the same.


> 
>>
>>> Therefore it should be a unique operation in the API.
>>>
>>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>> createVG would honor an optional list of devices (subset of
>>>>>>> devlist)
>>>>>>> whose
>>>>>>> partition tables should be trashed.
>>>>>>>
>>>>>>> Dan.
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>