Bug 1022691 - check database object ownership to engine before upgrade
Summary: check database object ownership to engine before upgrade
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.3.0
Assignee: Sandro Bonazzola
QA Contact: sefi litmanovich
URL:
Whiteboard: integration
Depends On:
Blocks: 3.3snap3
TreeView+ depends on / blocked
 
Reported: 2013-10-23 19:26 UTC by Alon Bar-Lev
Modified: 2014-01-21 22:29 UTC (History)
11 users (show)

Fixed In Version: is24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 951923 0 unspecified CLOSED [RFE] [db] create application objects within own schema 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 960063 0 unspecified CLOSED check DB objects before upgrade (owner engine) 2021-02-22 00:41:40 UTC
oVirt gerrit 20935 0 None None None Never
oVirt gerrit 20968 0 None None None Never
oVirt gerrit 21277 0 None None None Never

Internal Links: 951923 960063

Description Alon Bar-Lev 2013-10-23 19:26:01 UTC
During legacy backup/restore procedure, users used postgres user instead of engine user to restore, this leads to have object owned by postgres.

We need to abort setup in this case, asking user to run the ownership change script[1].

Eli, please specify sql statements to run and assign to sandaro.

Thanks!

[1] http://gerrit.ovirt.org/#/c/18682/

Comment 1 Eli Mesika 2013-10-24 05:34:44 UTC
(In reply to Alon Bar-Lev from comment #0)
> During legacy backup/restore procedure, users used postgres user instead of
> engine user to restore, this leads to have object owned by postgres.
> 
> We need to abort setup in this case, asking user to run the ownership change
> script[1].
> 
> Eli, please specify sql statements to run and assign to sandaro.

pg_dump -s  -h <server> -p <port> -U <user> <db>|grep -i 'owner to postgres' |wc -l

This should return 0 , if returns something greater than that , fail and ask the user to run the script [1]

[1] http://gerrit.ovirt.org/#/c/18682/

Comment 2 Alon Bar-Lev 2013-10-24 08:13:24 UTC
(In reply to Eli Mesika from comment #1)
> (In reply to Alon Bar-Lev from comment #0)
> > During legacy backup/restore procedure, users used postgres user instead of
> > engine user to restore, this leads to have object owned by postgres.
> > 
> > We need to abort setup in this case, asking user to run the ownership change
> > script[1].
> > 
> > Eli, please specify sql statements to run and assign to sandaro.
> 
> pg_dump -s  -h <server> -p <port> -U <user> <db>|grep -i 'owner to postgres'
> |wc -l
> 
> This should return 0 , if returns something greater than that , fail and ask
> the user to run the script [1]
> 
> [1] http://gerrit.ovirt.org/#/c/18682/

Eli, I am very sorry... but re-assign...

I would really really prefer to have sql statement for that that I can execute within opened connection to the database over using pg_dump. Is that possible?

Comment 3 Eli Mesika 2013-10-24 09:02:25 UTC
(In reply to Alon Bar-Lev from comment #2)
> (In reply to Eli Mesika from comment #1)
> > (In reply to Alon Bar-Lev from comment #0)

> I would really really prefer to have sql statement for that that I can
> execute within opened connection to the database over using pg_dump. Is that
> possible?


select nsp.nspname as object_schema,
       cls.relname as object_name,
       rol.rolname as owner,
       case cls.relkind
         when 'r' then 'TABLE'
         when 'i' then 'INDEX'
         when 'S' then 'SEQUENCE'
         when 'v' then 'VIEW'
         when 'c' then 'TYPE'
         else cls.relkind::text
       end as object_type
from pg_class cls
  join pg_roles rol on rol.oid = cls.relowner
  join pg_namespace nsp on nsp.oid = cls.relnamespace
where nsp.nspname not in ('information_schema', 'pg_catalog')
  and nsp.nspname not like 'pg_toast%'
  and rol.rolname != 'engine'
order by nsp.nspname, cls.relname;

Comment 4 Sandro Bonazzola 2013-11-07 14:38:53 UTC
merged on upstream master and 3.3 branches, 
 Change-Id: I45b655e88c25dd51e567405cc6747b42dfd8a98b

Comment 5 Alon Bar-Lev 2013-11-14 14:18:23 UTC
Not merged completely.

Comment 6 sefi litmanovich 2013-12-04 10:14:26 UTC
Verified on RHEL6.5 RHEVM3.3 IS25.

steps of verification:

1) on a running environment with rhevm3.2.5 sf22, entered with user engine to DB and altered ownership of users table from engine to postgres
2) upgraded rhevm to 3.3 IS25.
3) engine-setup:

Failed to execute stage 'Setup validation': Cannot upgrade the database schema due to wrong ownership of some database entities.
Please execute: /usr/share/ovirt-engine/setup/dbutils/changedbowner.sh -s localhost -p 5432 -d engine -f postgres -t engine
Using the password of the "postgres" user.

4)/usr/share/ovirt-engine/setup/dbutils/changedbowner.sh -s localhost -p 5432 -d engine -f postgres -t engine

5) engine-setup - works fine

Comment 7 Itamar Heim 2014-01-21 22:26:25 UTC
Closing - RHEV 3.3 Released

Comment 8 Itamar Heim 2014-01-21 22:29:50 UTC
Closing - RHEV 3.3 Released


Note You need to log in before you can comment on or make changes to this bug.