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 <didi(a)redhat.com>
wrote:
On Fri, Jul 15, 2022 at 10:31 AM Andrei Verovski <andreil1(a)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_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>
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