3:35 p.m.
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