On 14 Jul 2022, at 17:37, Moritz Baumann <moritz.baumann(a)inf.ethz.ch&gt; wrote: I had a similar issue. for me, taking the password from /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-grafana-database.conf (GRAFANA_DB_PASSWORD) and set that password in postgres for the user ovirt_engine_history_grafana did the trick. Best Mo On 7/14/22 16:28, Andrei Verovski wrote: > Hi, > I have oVirt engine 4.4.7 running on dedicated PC (not hosted engine). > After several unsuccessful upgrade attempts of 4.4.7 to 4.4.10 decided to install clean 4.4.10 and migrate data. > On old engine > engine-backup --scope=all --mode=backup > On new engine > engine-backup --mode=restore --provision-all-databases --no-restore-permissions --file=ovirt-engine-backup-20220713160717.backup > Result: > [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to database for grafana using existing credentials: ovirt_engine_history_grafana@localhost:5432 > How to Remove Grafana Completely During Engine Migration, or skip it during backup? > In fact it would be nice to delete it on active 4.4.7 setup, I don’t need it anyway. > Thanks in advance. > # — LOG ——————————————————————— > Start of engine-backup with mode 'restore' > scope: all > archive file: ovirt-engine-backup-20220713160717.backup > log file: /var/log/ovirt-engine-backup/ovirt-engine-restore-20220714170603.log > Preparing to restore: > - Unpacking file 'ovirt-engine-backup-20220713160717.backup' > Restoring: > - Files > Provisioning PostgreSQL users/databases: > - user 'engine', database 'engine' > - user 'ovirt_engine_history', database 'ovirt_engine_history' > Restoring: > - Engine database 'engine' > - Cleaning up temporary tables in engine database 'engine' > - Updating DbJustRestored VdcOption in engine database > - Resetting DwhCurrentlyRunning in dwh_history_timekeeping in engine database > - Resetting HA VM status > ------------------------------------------------------------------------------ > Please note: > The engine database was backed up at 2022-07-13 16:07:21.000000000 +0300 . > Objects that were added, removed or changed after this date, such as virtual > machines, disks, etc., are missing in the engine, and will probably require > recovery or recreation. > ------------------------------------------------------------------------------ > - DWH database 'ovirt_engine_history' > - Grafana database '/var/lib/grafana/grafana.db' > You should now run engine-setup. > Done. > [root@node00 ovirt-engine-backup]# engine-setup > [ INFO ] Stage: Initializing > [ INFO ] Stage: Environment setup > Configuration files: /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf, /etc/ovirt-engine-setup.conf.d/10-packaging.conf, /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf > Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20220714170757-7072xx.log > Version: otopi-1.9.6 (otopi-1.9.6-1.el8) > [ INFO ] The engine DB has been restored from a backup > [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to database for grafana using existing credentials: ovirt_engine_history_grafana@localhost:5432 > [ INFO ] Stage: Clean up > Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20220714170757-7072xx.log > [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20220714170806-setup.conf' > [ INFO ] Stage: Pre-termination > [ INFO ] Stage: Termination > [ ERROR ] Execution of setup failed > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7JORR5ZWZJT... _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZZOUZX65Q2E...

On 18 Jul 2022, at 15:35, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: On Fri, Jul 15, 2022 at 10:31 AM Andrei Verovski <andreil1(a)starlett.lv&gt; wrote: > > Hi, > > I did this and still struck at that Grafana stage. > > CREATE ROLE ovirt_engine_history_grafana; > ALTER DEFAULT PRIVILEGES FOR ROLE ovirt_engine_history IN SCHEMA public GRANT SELECT ON TABLES TO ovirt_engine_history_grafana; > ALTER ROLE ovirt_engine_history_grafana WITH PASSWORD ‘my_password’; You are probably missing pg_hba.conf configuration, see e.g. https://www.ovirt.org/documentation/data_warehouse_guide/#Allowing_Read_O... . > > > How to delete Grafana completely from old setup??? I don't think we have this documented anywhere. If you only want to get rid of the setup issue, it's probably enough to edit /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf, changing the line 'OVESETUP_GRAFANA_CORE/enable=bool:True' to 'OVESETUP_GRAFANA_CORE/enable=bool:False'. This will not "delete Grafana completely", only make engine-setup ignore it. > > > I don’t need it. > > Thanks in advance. > > > >> On 14 Jul 2022, at 17:37, Moritz Baumann <moritz.baumann(a)inf.ethz.ch&gt; wrote: >> >> I had a similar issue. >> >> for me, taking the password from >> /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-grafana-database.conf (GRAFANA_DB_PASSWORD) >> >> and set that password in postgres for the >> user ovirt_engine_history_grafana did the trick. >> >> Best >> Mo >> >> >> On 7/14/22 16:28, Andrei Verovski wrote: >>> Hi, >>> I have oVirt engine 4.4.7 running on dedicated PC (not hosted engine). >>> After several unsuccessful upgrade attempts of 4.4.7 to 4.4.10 decided to install clean 4.4.10 and migrate data. >>> On old engine >>> engine-backup --scope=all --mode=backup >>> On new engine >>> engine-backup --mode=restore --provision-all-databases --no-restore-permissions --file=ovirt-engine-backup-20220713160717.backup I am sorry to note that your issue was most likely caused by '--no-restore-permissions', although the documentation (including --help/manpage) does not hint about this at all. You might want to open a doc bug to document this, or even an RFE bug, to make this a separate option. for a long time, it was mandatory to pass either --no-restore-permissions or --restore-permissions: https://bugzilla.redhat.com/show_bug.cgi?id=1220791 But I recently changed this to default to --restore-permissions: https://bugzilla.redhat.com/1821018 With --restore-permissions, if you previously manually created extra users and gave them access permissions, e.g. using the doc in above link, --mode=restore could not know the passwords for these users, and created them with random passwords, outputting "- extra user '${extrau}' having grants on database ${database}, created with a random password": https://bugzilla.redhat.com/1369757 But for grafana, this isn't true - the password is saved in the above-mentioned conf, and so --mode=restore can (and does) create the user with the saved password: https://bugzilla.redhat.com/show_bug.cgi?id=1837460 Bottom line: I now think that --restore-permissions almost always makes sense, therefore changed it to be the default. If you have scripts/procedures that pass --no-restore-permissions, I recommend rethinking these and considering dropping it altogether, relying on the default, or passing --restore-permissions. A scenario I can think of where '--no-restore-permissions' does make sense: If you do have extra users you created for some other applications to access the DWH DB, and would rather not have a restore procedure replace their passwords to random ones, but prefer having your restore procedure handle this manually - restore/setup with --no-restore-permissions, then manually add the users+passwords you need and give them permissions. Best regards, -- Didi

On 19 Jul 2022, at 09:51, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: On Tue, Jul 19, 2022 at 9:38 AM Andrei Verovski <andreil1(a)starlett.lv&gt; wrote: > > Hi, > > > Thanks, I solved this problem before by means of executing these commands: > > su - postgres -s/bin/bash > psql -d ovirt_engine_history > > CREATE ROLE ovirt_engine_history_grafana; > ALTER DEFAULT PRIVILEGES FOR ROLE ovirt_engine_history IN SCHEMA public GRANT SELECT ON TABLES TO ovirt_engine_history_grafana; > ALTER ROLE ovirt_engine_history_grafana WITH ENCRYPTED PASSWORD ‘my_password'; > ALTER ROLE ovirt_engine_history_grafana WITH LOGIN; So this last one, 'LOGIN', was the missing part. OK. Thanks for the update. Glad to hear that you solved it! Any other conclusions/suggestions you'd like to make?

Best regards, -- Didi