[Engine-devel] getDeviceList should report partioned devices, too
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. Dan.
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 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) Thanks, Livnat
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.
On 18/01/12 12:44, Dan Kenigsberg wrote:
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.
ok great thanks. you can push it and will take care of the engine side. Thanks, Livnat
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 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. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
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: []}) createVG would honor an optional list of devices (subset of devlist) whose partition tables should be trashed. Dan.
----- 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.
----- 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.
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.
----- 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.
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 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
----- Original Message ----- formatStorageDomain-removeVG functions.
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:
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
----- Original Message ----- 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. >
----- Original Message -----
On 22/01/12 10:05, Eduardo Warszawski wrote:
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
----- Original Message ----- 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. >> >
participants (4)
-
Ayal Baron -
Dan Kenigsberg -
Eduardo Warszawski -
Livnat Peer