Thanks for your explanation. Just one more clarification. See below
On Fri, Aug 3, 2018 at 5:06 PM, Jan Siml <jsiml(a)plusline.net> wrote:
Hello,
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?
>
No, WUI was down because service was stopped by engine-setup and not
started afterwards when restore of DB backups failed. But starting
ovirt-engine service brought engine and WUI up.
Can you confirm if also in your case the rollback of the db failed? If so,
how could you be sure of the consistency of the database if only a partial
restore has been executed and the pg_restore command failed?
So after manually starting the engine service you were able to connect and
delete from GUI the transfer, correct?
>
> - 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?
>
Yes, just inspected the table, deleted one row with the mentioned stament
and sucessfully retried the upgrade.
Regards
Jan
So after the GUI deletion of the wrong transfer you executed engine-setup
again; did you choose to backup the db or not when proposed?
after the error you manually deleted and executed again engine-setup
So at the end you run 3 times the engine-setup program?
It remains my doubt about the status of the engine database due to
pg_restore failed in the middle, so some tables/objects could have the old
structure and some tables the new.
It should be analyzed in your case from 4.2.4 to 4.2.5 what are the db
operation to execute duting upgrade and in my case when trying to pass
from 4.2.3 to 4.2.5
Gianluca