Eli,
should we necessary call it while the engine is still in maintenance mode or not active or could we also run it against a running engine?

(In reply to Simone Tiraboschi from comment #1)
> Eli,
> should we necessary call it while the engine is still in maintenance mode or
> not active or could we also run it against a running engine?

in maintenance mode

Created attachment 1014336 [details]
engine-setup log

I got this error:
[ ERROR ] Failed to execute stage 'Setup validation': Failed to unlock entities. Please access support in attempt to resolve the problem
after upgrade of oVirt from 3.5.1 to 3.6, is it the same as this one? (should I move it to ASSIGNED)

It should be already fixed there:
https://gerrit.ovirt.org/#/c/39687/

I'm not sure that was already in your buid.

I tried to update from 3.5.1.
While I perform "yum update" the package ovirt-engine-backend is still in version 3.5.1

so during the engine-setup it fails at:

       Please confirm installation settings (OK, Cancel) [OK]: 
[ INFO  ] Cleaning async tasks and compensations
[ INFO  ] Unlocking existing entities
[ ERROR ] Failed to execute stage 'Setup validation': Failed to unlock entities. Please access support in attempt to resolve the problem

in log is the same exception as provided in comment #3

this issue blocks upgrade from 3.5.1 to 3.6

additional info:
ovirt-engine-setup-3.6.0-0.0.master.20150412172306.git55ba764.el6.noarch

patch https://gerrit.ovirt.org/#/c/39687/ was merged on April 13th so, for sure, is not in ovirt-engine-setup-3.6.0-0.0.master.20150412172306.git55ba764.el6.noarch which is from April 12th.

Can you please retry with a fresher build?

Hi, I used these steps from https://mojo.redhat.com/docs/DOC-1021085 to install ovirt but it seems that it doesn't provide latest ovirt build. So I install it from ovirt.org.

When I tried to upgrade from ovirt 3.5.1 to 3.6.0 with zombie task (make a template) it is not successful. After upgrade the affected VM was still locked with any incompleted task. 

I tried run engine-setup again on 3.6.0 and the VM was successfully unlocked.

Attached:
logs from upgrade 3.5.1 -> 3.6.0 (engine-logs.tar.gz)
logs from engine-setup 3.6.0 -> 3.6.0 (engine-logs_2.tar.gz)

used:
ovirt-engine-setup-3.6.0-0.0.master.20150416173208.git88a29e5.el6.noarch

Created attachment 1015510 [details]
3.5.1 >> 3.6.0

Created attachment 1015511 [details]
3.6.0 >> 3.6.0 (engine-setup)

Without any update of ovirt packages. Just performed engine-setup again

Eli,
now unlock_entity.sh is in the right place and so the upgrade script founds it.

But unlock_entity.sh it's still failing by itself in 3.5.1 >> 3.6.0 upgrades cause fn_db_unlock_all SQL function is still not available on 3.5.0.


2015-04-17 10:57:36 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.upgrade.asynctasks plugin.execute:939 execute-output: ('/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh', '-t', 'all', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20150417105649-q89e0o.log', '-u', 'engine', '-s', 'localhost', '-p', '5432', '-d', 'engine') stderr:
ERROR:  function fn_db_unlock_all() does not exist
LINE 1: select fn_db_unlock_all();
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.


Can you please check it?
Do we need to add fn_db_unlock_all SQL function in the next 3.5.z or should we create it from 3.6 setup?

(In reply to Simone Tiraboschi from comment #10)
> Eli,
> now unlock_entity.sh is in the right place and so the upgrade script founds
> it.
> 
> Can you please check it?
> Do we need to add fn_db_unlock_all SQL function in the next 3.5.z or should
> we create it from 3.6 setup?

I didn't knew that this should be back-ported to 3.5, the right way is to add this function to the next 3.5.z

Eli, my one was not an assertion, it was just a question.

The claim is that we must support upgrade from latest 3.5.z to 3.6.0.

So if upgrading to 3.6.0 we are calling unlock_entity.sh, as we are doing now, are the required SQL code should be already there.
Two options:
- backport that SQL function also to the latest 3.5.z so that it would be already available upgrading to 3.6.0
- copy/duplicate that SQL function (and all it's dependencies) to a new packaging/setup/dbutils/unlock_entity.sql files so that it would be already available at that point

Both of them are viable, what do you suggest?

(In reply to Simone Tiraboschi from comment #12)
> Eli, my one was not an assertion, it was just a question.
> 
> The claim is that we must support upgrade from latest 3.5.z to 3.6.0.
> 
> So if upgrading to 3.6.0 we are calling unlock_entity.sh, as we are doing
> now, are the required SQL code should be already there.
> Two options:
> - backport that SQL function also to the latest 3.5.z so that it would be
> already available upgrading to 3.6.0
> - copy/duplicate that SQL function (and all it's dependencies) to a new
> packaging/setup/dbutils/unlock_entity.sql files so that it would be already
> available at that point
> 
> Both of them are viable, what do you suggest?

I would simply go for option 1

Thinking about it twice, option 1 isn't probably the best option cause now we cannot release it before 3.5.3 ans so upgrades from 3.5.2 RCx to 3.6-master-snapshot are still going to fail and this is not that good.

Bug #1177735 has been verified without this bug fixes, so this can't be a blocker for it. Dropping.

Bug #1200454 has been verified without this bug fixes, so this can't be a blocker for it. Dropping.

Moving to modified, all referenced patches have been merged.

Verified:
ovirt-engine-3.5.2.1-1.el6.noarch >> ovirt-engine-3.6.0-0.0.master.20150519172219.git9a2e2b3.el6.noarch