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

Bug 1861797

Summary: restore of DWH doesn't create grafana user
Product: [oVirt] ovirt-engine Reporter: Lucie Leistnerova <lleistne>
Component: Backup-Restore.EngineAssignee: Yedidyah Bar David <didi>
Status: CLOSED NOTABUG QA Contact: Lucie Leistnerova <lleistne>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4.1.10CC: bugs, didi, sbonazzo
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-30 06:35:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Metrics RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lucie Leistnerova 2020-07-29 15:11:45 UTC
Description of problem:
When migrating DWH to remote machine restore doesn't create grafana database user and fails to install.

Version-Release number of selected component (if applicable):
ovirt-engine-tools-backup-4.4.1.10-0.1.el8ev.noarch
ovirt-engine-dwh-setup-4.4.1.2-1.el8ev.noarch

How reproducible: always


Steps to Reproduce:
1. on engine
# engine-backup --mode=backup --scope=dwhdb --scope=files --file=/tmp/dwh.bck --log=/tmp/bck.log
2. copy the file to other machine and restore
# yum module -y enable postgresql:12 pki-deps
# yum module reset virt
# yum module enable virt:8.2
# yum install ovirt-engine-tools-backup
# yum install postgresql-server postgresql-contrib
# su - postgres -c 'initdb'
# systemctl start postgresql
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=/tmp/dwh.bck  --log=/tmp/bck.log --provision-dwh-db --no-restore-permissions
3. run engine-setup

Actual results: engine-setup fails with
[ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to database for grafana using existing credentials: ovirt_engine_history_grafana@localhost:5432


Expected results: engine-setup succeeded and grafana is running


Additional info: postgres users:
postgres=# \du
                                         List of roles
      Role name       |                         Attributes                         | Member of 
----------------------+------------------------------------------------------------+-----------
 ovirt_engine_history |                                                            | {}
 postgres             | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

WA is to remove grafana config
/etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-grafana-database.conf

Comment 1 Yedidyah Bar David 2020-07-30 06:03:08 UTC
Please try again, but use this restore command:

engine-backup --mode=restore --file=/tmp/dwh.bck  --log=/tmp/bck.log --provision-all-databases

Thanks. This is the command I recommend for all restores (in 4.3+, when db was provisioned automatically originally), generally speaking. Already talked with doc team about this, not sure I opened a bug. Perhaps I should.

If you want to test the minimal possible change, you can try this instead:

engine-backup --mode=restore --scope=files --scope=dwhdb --file=/tmp/dwh.bck  --log=/tmp/bck.log --provision-dwh-db --restore-permissions

That is, "--restore-permissions" instead of "--no-restore-permissions". I now recommend to always use "--restore-permissions" when provisioning databases, or drop it altogether, if provisioning databases - as then this is the default. See also bug 1530031.

Assuming this does work, we still have a bug :-). I wonder if it's ok to treat it as a doc bug (just change to --restore-permissions or drop it altogether, relying on defaults), or a code bug (as one might expect grafana user to be restored even if other permissions are not restored).

Comment 2 Lucie Leistnerova 2020-07-30 06:35:58 UTC
I was testing migration only of DWH, so why to use restore-all-databases? It doesn't make much sense for me.
I followed the documentation
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4-beta/html-single/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_cockpit_web_interface/index#Migrating_Data_Warehouse_to_a_Separate_Machine_SHE_cockpit_deploy

But you are right --no-restore-permissions explains it, sorry my fault. So this is a doc bug and will be fixed as part of Bug 1860067.

Comment 3 Yedidyah Bar David 2020-07-30 07:31:31 UTC
(In reply to Lucie Leistnerova from comment #2)
> I was testing migration only of DWH, so why to use restore-all-databases? It
> doesn't make much sense for me.

You mean provision-all-databases? engine-backup --help says:

 --provision-all-databases          on restore, create a PostgreSQL database for all the
                                    databases that were included in the backup

I think this makes sense, no? You backed up only dwh (and files), that's what will
be provisioned.

I even consider doing this (provision-all-databases) the default, if all of
the backed up databases were local. Didn't file a bug/RFE for this. What do
you think?

> I followed the documentation
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4-
> beta/html-single/installing_red_hat_virtualization_as_a_self-
> hosted_engine_using_the_cockpit_web_interface/
> index#Migrating_Data_Warehouse_to_a_Separate_Machine_SHE_cockpit_deploy
> 
> But you are right --no-restore-permissions explains it, sorry my fault. So
> this is a doc bug and will be fixed as part of Bug 1860067.

Very well. Thanks!