----- Original Message -----
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.
You're asking the wrong question hence getting the wrong answers. vdsm is committed to backward compatibility of 1 version, hence no verb will be actually 'removed' from vdsm API until a new verb has been introduced and used side by side for at least 1 version. This is *always* true and if this is broken it is a bug that will be fixed.
Now that we've got that out of the way, wrt the current flow - no changes should be made in createVG, only in createStorageDomain.
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. >> >