----- 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.
> >>>
> >>
>
>
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
