Bug 1202333

Summary: VM is still locked after cleaning task "make a template" during the update
Product: Red Hat Enterprise Virtualization Manager Reporter: Petr Kubica <pkubica>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Kubica <pkubica>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: didi, emesika, gklein, lsurette, oourfali, pstehlik, rbalakri, Rhev-m-bugs, srevivo, stirabos, ykaul
Target Milestone: ovirt-3.6.0-rc   
Target Release: 3.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: OVIRT 3.6.0-3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-20 01:39:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1204673    
Attachments:
Description Flags
engine-logs none

Description Petr Kubica 2015-03-16 12:34:25 UTC 
Created attachment 1002241 [details]
engine-logs

Description of problem:
I tested this bug https://bugzilla.redhat.com/show_bug.cgi?id=1197616 
Now it clean all task from command_entites table and upgrading to vt13.15 from av14.3 is successful, but after upgrade, the VM is still locked forever..

in tab Tasks in webadmin is only "[No jobs available]"

Version-Release number of selected component (if applicable):
upgrade from av14.3 to vt13.15

How reproducible:
100%

Steps to Reproduce:
1. Start a template creation on av14.3
2. Stop the engine
3. Upgrade to vt13.15

Actual results:
VM is still locked

Expected results:
VM should be unlocked

Additional info:
Attached log from engine
Comment 1 Oved Ourfali 2015-03-18 09:36:06 UTC 
Eli, what should free the lock?
Comment 2 Eli Mesika 2015-03-18 10:12:29 UTC 
(In reply to Oved Ourfali from comment #1)
> Eli, what should free the lock?

I an not sure if engine-setup calls the unlock_entity.sh utility, but at least unlock_entity.sh can be called manually to release the lock.

Didi, does engine-setup suggests cleaning of locked entities using unlock_entity.sh ???
Comment 3 Simone Tiraboschi 2015-03-18 10:24:26 UTC 
No, engine-setup doesn't call unlock_entity.sh at all.

Should we explicitly unlock everything locked on each upgrade?
Comment 4 Eli Mesika 2015-03-18 10:29:08 UTC 
(In reply to Simone Tiraboschi from comment #3)
> No, engine-setup doesn't call unlock_entity.sh at all.
> 
> Should we explicitly unlock everything locked on each upgrade?

I think that we should run in engine-setup at least  unlock_entity.sh -q
this should return a list of locked entities 
If the list is not empty, IMO , engine-setup should suggest unlocking of those entities
Comment 5 Simone Tiraboschi 2015-03-18 10:45:46 UTC 
On my opinion it would be much better if entity got unlocked on task completion/deletion.
If task_cleaner.sh removed a task cause it detected that it would never ended (zombie), why should we keep the corresponding entity locked if no task need to keep it locked anymore?
Comment 6 Oved Ourfali 2015-03-18 12:15:37 UTC 
(In reply to Simone Tiraboschi from comment #5)
> On my opinion it would be much better if entity got unlocked on task
> completion/deletion.
> If task_cleaner.sh removed a task cause it detected that it would never
> ended (zombie), why should we keep the corresponding entity locked if no
> task need to keep it locked anymore?

We don't have this info at a task level. I agree with Eli that it should run on setup, as it would help overcome others issues that customers might experience due to various issues. In my opinion no object should be locked after upgrade. The task deletion is NY user approval? If so, I'd run unlock as well if it got approved.
Comment 7 Simone Tiraboschi 2015-03-18 17:31:32 UTC 
Zombie are deleted without asking any confirmation prior to other check, than we ask if he want to wait for other running task and if he respond no we abort.

We need to delete zombies before start waiting otherwise we will wait forever.

Could I call unlock_entity.sh to unlock everything in a single shot at the end of the upgrade procedure?
Comment 8 Oved Ourfali 2015-03-19 06:12:12 UTC 
(In reply to Simone Tiraboschi from comment #7)
> Zombie are deleted without asking any confirmation prior to other check,
> than we ask if he want to wait for other running task and if he respond no
> we abort.
> 
> We need to delete zombies before start waiting otherwise we will wait
> forever.
> 
> Could I call unlock_entity.sh to unlock everything in a single shot at the
> end of the upgrade procedure?

I think that it will be the simplest way to go.
Eli - can you confirm?
Comment 9 Eli Mesika 2015-03-19 09:56:50 UTC 
(In reply to Oved Ourfali from comment #8)
> (In reply to Simone Tiraboschi from comment #7)
> > Zombie are deleted without asking any confirmation prior to other check,
> > than we ask if he want to wait for other running task and if he respond no
> > we abort.
> > 
> > We need to delete zombies before start waiting otherwise we will wait
> > forever.
> > 
> > Could I call unlock_entity.sh to unlock everything in a single shot at the
> > end of the upgrade procedure?
> 
> I think that it will be the simplest way to go.
> Eli - can you confirm?

We don't have this ability today but I guess we can extend the utility to cover total cleanup of all entity locks
Comment 10 Eli Mesika 2015-03-23 09:19:28 UTC 
For a complete solution, this should be called from the engine-setup in order to unlock all locked entities, should I open a separate BZ for that ???
Comment 11 Oved Ourfali 2015-03-23 09:22:05 UTC 
(In reply to Eli Mesika from comment #10)
> For a complete solution, this should be called from the engine-setup in
> order to unlock all locked entities, should I open a separate BZ for that ???

Yes. Mark it as integration.
Comment 12 Petr Kubica 2015-07-29 08:22:15 UTC 
Verified in 3.6.0-0.0.master.20150627185750.git6f063c1.el6
update from ovirt 3.5 to 3.6.0-3