----- 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.
VG's can be created, removed, etc. using lvm tools.
VDSM is only about Storage Domains and not a VG manager.
What's the point of creating a VG using VDSM if not for building a SD?
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.
>>>
>>