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

[Ayal Baron]

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