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; my_password from: /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-grafana-database.conf > On 18 Jul 2022, at 15:35, Yedidyah Bar David <d...@redhat.com> wrote: > > 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/CJ6JKNNFGVLCL3F5C36AD5LXSXSLOGFV/
