Bug 1031717 - Force removal of DataCenter fails to remove vm_pool from DB
Summary: Force removal of DataCenter fails to remove vm_pool from DB
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.4.0
Assignee: Omer Frenkel
QA Contact: sefi litmanovich
URL:
Whiteboard: virt
Depends On:
Blocks: 1069219 rhev3.4beta 1142926
TreeView+ depends on / blocked
 
Reported: 2013-11-18 15:28 UTC by sefi litmanovich
Modified: 2014-09-18 12:24 UTC (History)
11 users (show)

Fixed In Version: ovirt-3.4.0-beta3
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1069219 (view as bug list)
Environment:
Last Closed: 2014-06-12 14:04:59 UTC
oVirt Team: ---
Target Upstream Version:


Attachments (Terms of Use)
engine.log (1.51 MB, text/x-log)
2013-11-18 15:28 UTC, sefi litmanovich
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 24130 0 None None None Never
oVirt gerrit 24405 0 None None None Never

Description sefi litmanovich 2013-11-18 15:28:16 UTC
Created attachment 825729 [details]
engine.log

Description of problem:

Force removal of DataCenter fails to remove a vm_pool that was created on this DC from the vm_pool table in DB.
After I force removed the DC, all the vms from that pool were deleted and the vm_pool was delted from the webadmin manue.
I then tried to remove the cluster which was related to the deleted DC and that failed.
looking at engine.log I saw the following ERROR:

2013-11-18 17:02:16,368 ERROR [org.ovirt.engine.core.bll.RemoveVdsGroupCommand] (pool-5-thread-50) [56101ce] Command org.ovirt.eng
ine.core.bll.RemoveVdsGroupCommand throw exception: org.springframework.dao.DataIntegrityViolationException: CallableStatementCall
back; SQL [{call deletevdsgroup(?)}]; ERROR: update or delete on table "vds_groups" violates foreign key constraint "fk_vds_groups
_vm_pools" on table "vm_pools"
  Detail: Key (vds_group_id)=(feace1c4-bae7-412a-9684-24d20813fedc) is still referenced from table "vm_pools".
  Where: SQL statement "DELETE FROM vds_groups WHERE vds_group_id =  $1 "
PL/pgSQL function "deletevdsgroup" line 7 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: update o
r delete on table "vds_groups" violates foreign key constraint "fk_vds_groups_vm_pools" on table "vm_pools"
  Detail: Key (vds_group_id)=(feace1c4-bae7-412a-9684-24d20813fedc) is still referenced from table "vm_pools".
  Where: SQL statement "DELETE FROM vds_groups WHERE vds_group_id =  $1 "
PL/pgSQL function "deletevdsgroup" line 7 at SQL statement......

I then saw the pool I once created was still existing in vm_pool table in DB.
After manually deleting it, cluster removal worked just fine.


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


Steps to Reproduce:
1.create DC-cluster-host-vmpool
2.create more dc's and cluster and detach the first one from any hosts.
3.force remove first Dc
4. remove cluster

Actual results:

1. upon removal of DC vm's from pool and pool itself do not appear in webadmin.
2. vm pool isn't deleted from DB
3. remove cluster fails

Expected results:

1. upon removal of DC vm's from pool and pool itself do not appear in webadmin.
2. vm pool is deleted from DB
3. remove cluster succeds

Comment 3 Sandro Bonazzola 2014-02-19 11:58:46 UTC
all patches merged

Comment 4 Sandro Bonazzola 2014-02-19 12:26:56 UTC
This bug is referenced in ovirt-engine-3.4.0-beta3 logs. Moving to ON_QA

Comment 6 sefi litmanovich 2014-02-23 10:31:56 UTC
Verified with ovirt-engine-3.4.0-0.11.beta3.el6.noarch.

reproduced according to the steps mentioned on bz description:

1) created DC-cluster-host
2)created vm - template - vm pool
3) created a new DC-cluster
4) attached the host to the new DC-Cluster
5) Force removed original DC
6) Verified that the vm pool was deleted from DB
7) removed the original cluster - worked with no failure

Comment 8 Itamar Heim 2014-06-12 14:04:59 UTC
Closing as part of 3.4.0


Note You need to log in before you can comment on or make changes to this bug.