On Fri, Jul 15, 2022 at 10:31 AM Andrei Verovski <andre...@starlett.lv> 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_Only_Access_to_the_History_Database . > > > 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.baum...@inf.ethz.ch> 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 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/YMNPAFLEQ62O6BYJVA6NNMCTGUCS3EWA/
