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

Livnat Peer lpeer at redhat.com
Sun Jan 22 07:42:06 UTC 2012


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.

> 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.
>>>>>
>>>>
>>
>>




More information about the Devel mailing list