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
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).
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.
(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!