On Sun, Jan 08, 2012 at 03:08:13PM +0200, Dan Kenigsberg wrote: > Hi Lists, > > One cannot create a PV on a partitioned device, and therefor such > devices where not reported to Engine. This proved surprising to users > who woder where their LUN disappeared. > > Vdsm should report all devices, and ovirt-engine should mark partitioned > devices as unworthy of a PV. In the future, Vdsm may allow to forcefully > remove a partition table from a device, to make it usable as a PV. > > Douglas (CCed) would take resposibilty on the Vdsm side. Initial patch at > http://gerrit.ovirt.org/944 sports a backword-compatible API. Who's taking this > on Engine? This involves GUI, too, as partitioned devices should probably be > displayed greyed-out. Livnat, is there any taker for this on your side? Since the change is backward-compatible, I would push it if there are no objections. Dan.

On Tue, Jan 17, 2012 at 07:46:17PM +0200, Livnat Peer wrote: > On 17/01/12 16:08, Dan Kenigsberg wrote: >> On Sun, Jan 08, 2012 at 03:08:13PM +0200, Dan Kenigsberg wrote: >>> Hi Lists, >>> >>> One cannot create a PV on a partitioned device, and therefor such >>> devices where not reported to Engine. This proved surprising to users >>> who woder where their LUN disappeared. >>> >>> Vdsm should report all devices, and ovirt-engine should mark partitioned >>> devices as unworthy of a PV. In the future, Vdsm may allow to forcefully >>> remove a partition table from a device, to make it usable as a PV. >>> >>> Douglas (CCed) would take resposibilty on the Vdsm side. Initial patch at >>> http://gerrit.ovirt.org/944 sports a backword-compatible API. Who's taking this >>> on Engine? This involves GUI, too, as partitioned devices should probably be >>> displayed greyed-out. >> >> Livnat, is there any taker for this on your side? >> >> Since the change is backward-compatible, I would push it if there are no >> objections. >> >> Dan. > > Hi Danken, > > How did you mark a partitioned device? (How will the engine will spot > these LUNs) Each device has a field 'partitioned'. Currently, Engine ignores it (as it is always False). With my little patch, devices with partitioned=True would be reported, too. Dan.

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

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

> > createVG would honor an optional list of devices (subset of > devlist) > whose > partition tables should be trashed. > > Dan. >

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?

>> >>> >>> createVG would honor an optional list of devices (subset of >>> devlist) >>> whose >>> partition tables should be trashed. >>> >>> Dan. >>> >>

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

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.

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