Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1064903

Summary: engine-backup --mode=restore should point to documentation on failure
Product: [Retired] oVirt Reporter: Antoni Segura Puimedon <asegurap>
Component: ovirt-engine-installerAssignee: Yedidyah Bar David <didi>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Beňas <pbenas>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.4CC: acathrow, bazulay, didi, emesika, gklein, iheim, pstehlik, talayan, yeylon
Target Milestone: ---Keywords: Reopened
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: integration
Fixed In Version: ovirt-3.4.0-beta3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-31 12:23:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Antoni Segura Puimedon 2014-02-13 14:13:50 UTC
Description of problem:
When migrating the engine to freshly installed machine, like for example in the
case that you are doing a migration to the new "Hosted engine" calling:
    engine-backup --mode=restore --file=<your_backup_file> \
    --log=<your_backup_log> --change-db-credentials \
    --db-host=<your_host_name> -lap --db-user=engine --db-password \
    --db-name=engine"

The operation fails as the backup restore expects psql to have an engine
database. So the user has to go to psql and create an engine role and
an engine database with owner 'engine'.

Version-Release number of selected component (if applicable):
ovirt-engine-tools-3.4.0-0.7.beta2.fc19.noarch

How reproducible: 100%


Steps to Reproduce:
1. Make a backup of your engine database:
    engine-backup --mode=backup --file=<your_backup_file> --log=backup1.log
2. Install Fedora or EL6 on a different host or VM
3. Install the engine
    yum install ovirt-engine
4. Move the backup over to the new host/VM
    scp <your_backup_file> <target_host_ip>:/tmp/
5. Restore the old database onto the new host
    engine-backup --mode=restore --file=/tmp/<your_backup_file> \
    --log=<your_backup_log> --change-db-credentials \
    --db-host=<your_host_name> -lap --db-user=engine --db-password \
    --db-name=engine"

Actual results:
Authentication to the database fails as there is no engine database nor
engine role.

Expected results:
engine-backup notices the fact that there is no engine database/role and
creates the appropriate settings so it can do the restore.

For reference, what I had to do was:
    psql -U postgres -W
    Inside the psql console
        CREATE ROLE engine WITH LOGIN PASSWORD <my_password>;
        CREATE DATABASE engine WITH OWNER engine;
        COMMIT;
    

Optionally it asks the user if it wants to run engine-setup to finish the
migration.

At the very least it should point the user to the workaround above (during the
test day it happened to at least 2 people on #ovirt and we finally came to the
same workaround, but it was a more painful process than it should be).

Comment 1 Yedidyah Bar David 2014-02-13 14:51:28 UTC

*** This bug has been marked as a duplicate of bug 1064503 ***

Comment 2 Yedidyah Bar David 2014-02-13 14:53:24 UTC
(In reply to Antoni Segura Puimedon from comment #0)
> For reference, what I had to do was:
>     psql -U postgres -W
>     Inside the psql console
>         CREATE ROLE engine WITH LOGIN PASSWORD <my_password>;
>         CREATE DATABASE engine WITH OWNER engine;
>         COMMIT;
>     
> 
> Optionally it asks the user if it wants to run engine-setup to finish the
> migration.
> 
> At the very least it should point the user to the workaround above (during
> the
> test day it happened to at least 2 people on #ovirt and we finally came to
> the
> same workaround, but it was a more painful process than it should be).

Note that this isn't a "workaround", it's what appears in 'engine-backup --help'.

Comment 3 Antoni Segura Puimedon 2014-02-13 14:57:42 UTC
@Yedidyah: The point is that it should not be just in engine-backup --help (which I did not see before doing this), the point is that if it fails due to this reason it should detect it and if it can't fix it, it should at least give the instructions at that very moment.

Comment 4 Yedidyah Bar David 2014-02-13 15:18:10 UTC
(In reply to Antoni Segura Puimedon from comment #3)
> @Yedidyah: The point is that it should not be just in engine-backup --help
> (which I did not see before doing this), the point is that if it fails due
> to this reason it should detect it and if it can't fix it, it should at
> least give the instructions at that very moment.

OK, makes sense.

Comment 5 Itamar Heim 2014-02-16 08:23:12 UTC
Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 6 Yedidyah Bar David 2014-02-17 13:25:22 UTC
24542 adds on failure a suggestion to run --help.

Added to the help text a link to http://www.ovirt.org/Ovirt-engine-backup .

Added there a Howto section.

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

Comment 8 Petr Beňas 2014-02-26 14:00:52 UTC
Tested in ovirt-engine-tools-3.4.0-0.11.beta3.el6.noarch.

The fix is not what was requested in comment 0 and agreed in comment 4. It is not the described situation specific. 
Moving to verified anyway since the requested feature seems to be tracked by the bug 1064503 .

Comment 9 Sandro Bonazzola 2014-03-31 12:23:29 UTC
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released