On Fri, Aug 3, 2018 at 4:09 PM, Jan Siml <jsiml@plusline.net> wrote:

Hello,

On 03.08.2018 15:52, Gianluca Cecchi wrote:

On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net <mailto:jsiml@plusline.net>> wrote:

Hello,

There are probably some more stale image transfers records,
can you please check whether 'image_transfers' table is empty?
If not, you can try removing them by executing:
"DELETE FROM image_transfers WHERE command_id NOT IN (SELECT
command_entities.command_id FROM command_entities);"
(you can simply prepend it to
'04_02_1210_add_foreign_key_to_image_transfers.sql')

that's how it worked and the update was successful. Thanks!

Jan,
are you saying that after your second update failure that failed also the the restore of the databases, you added the delete statement into the 04_02_1210_add_foreign_key_to_image_transfers.sql script?
How? because the yum rollback phase completed in my case so under /usr/share/ovirt-engine/dbscripts/upgrade/ I currently don't have it...
And the first update error leaves the engine down....

I checked the table in psql and found only one row. Then I used the above statement to delete the orphaned row and retried the update. Worked.

Regards

Jan

So your workflow was:

- run engine-setup and got failure

was it able in your case to restore the engine db in this first run and start engine again?

You wrote that there was an upload failure and that you removed it: did you mean you removed it from the GUI, and confirming that after first failure the webadmin gui was still reachable?

In my case after first run failure, my engine is down and trying to reach I get:

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

- run engine-setup again and got failure

It seems that after this second failure your engine and dwh db are down, so also the engine portal...

Then you manually execute the delete statement

- engine-setup again and it succeeds

Correct?

Gianluca