Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 990524

Summary:	storage_pool_id column at async_tasks always contains the empty GUID value
Product:	[Retired] oVirt	Reporter:	Yair Zaslavsky <yzaslavs>
Component:	ovirt-engine-core	Assignee:	Yair Zaslavsky <yzaslavs>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3	CC:	acathrow, iheim, lpeer, obasan, oourfali, Rhev-m-bugs, yeylon
Target Milestone:	---	Keywords:	Regression
Target Release:	3.3
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-23 07:30:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Yair Zaslavsky 2013-07-31 11:43:18 UTC

Description of problem:

The value of storage_pool_id at async_tasks table always equals to the empty guid value (00000000-0000-0000-0000-000000000000) instead of holding the id of the the data center (storage pool) which the tasks runs on its SPM.

This did not happen in version 3.2, as from 3.3, the tasks are created in DB prior to their execution on VDSM.
The "InsertOrUpdateAsyncTasks" stored procedure never updated the storage pool id, and once vdsm task id is returned to engine, this is the stored procedure being used.
This should be fixed.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Yair Zaslavsky 2013-07-31 11:46:38 UTC

At version 3.2 - the task was added to db when vdsm task id was returned from the SPM host, and the Insertasync_tasks stored procedure which inserts the storage_pool_id is used.

Comment 3 Itamar Heim 2013-08-21 16:39:32 UTC

as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)

Comment 4 Itamar Heim 2013-09-23 07:30:40 UTC

closing as this should be in 3.3 (doing so in bulk, so may be incorrect)