Bug 818111

Summary: ovirt-engine-backend [Task Manager]: removing template will show uuid instead of template name
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: ovirt-engineAssignee: Omer Frenkel <ofrenkel>
Status: CLOSED CURRENTRELEASE QA Contact: Dafna Ron <dron>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.1.0CC: acathrow, dyasny, iheim, lpeer, michal.skrivanek, ofrenkel, Rhev-m-bugs, yeylon, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: virt
Fixed In Version: SI6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:
Attachments:
Description Flags
log none

Description Dafna Ron 2012-05-02 08:57:11 UTC
Created attachment 581545 [details]
log

Description of problem:

removing a template from the export domain will show the task with the template uuid and not the template name. 

talking to Moti, the reason we show uuid is if the object does not exists (for example if we try to delete and object that was already delete). 

so I tested a delete of template that exists in both export and setup and we can see the template name. 
however, when we delete a template that no longer exists in the setup from the export domain we get the uuid so it seems are query is running on the wrong domain. 

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

si2.1

How reproducible:

100%

Steps to Reproduce:
1. remove a template from Export domain 
2.
3.
  
Actual results:

the task will be shown with the template uuid and not the template name 

Expected results:

we should query the export domain and not the setup domain and show template name. 

Additional info: log

Comment 1 Omer Frenkel 2012-05-23 15:21:00 UTC
also fixed domain name which wasn't correct and same for vm that had the same problem
http://gerrit.ovirt.org/#change,4714

Comment 3 Dafna Ron 2012-06-14 13:46:50 UTC
verified on si6