Bug 2026473

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

2021-11-24 17:53:33,871+0100 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:234 Database: 'None', Statement: '
                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_%%' and
                    cls.relname not like 'pg_%%' and
                    rol.rolname != %(user)s
                order by
                    nsp.nspname,
                    cls.relname
            ', args: {'user': 'engine'}
2021-11-24 17:53:33,872+0100 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:239 Creating own connection
2021-11-24 17:53:33,887+0100 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:284 Result: [{'object_schema': 'public', 'object_name': 'fk_info_rs', 'owner': 'postgres', 'object_type': 'TYPE'}]

A short update on investigation 

It seems that  DB validations plugin executed from packaging/setup/plugins/ovirt-engine-setup/ovirt-engine/upgrade/dbvalidations.py is executing the fkvalidator.sh with the "postgres" user instead of the "engine"
fkvalidator.sh creates some helper db objects on-the-fly 

As a result , the database validation _checkDatabaseOwnership function in packaging/setup/plugins/ovirt-engine-setup/ovirt-engine/db/schema.py fails because it finds some db objects owned by "postgres" instead of by "engine"

for example , the following TYPE:

[{'object_schema': 'public', 'object_name': 'fk_info_rs', 'owner': 'postgres', 'object_type': 'TYPE'}]

Please attach a database dump in order to verify that this is the problem

Hey Eli,
Thanks for your time.
We were able to fix our problem by first verifying the result of the query:

engine=# 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_%%' and
                    cls.relname not like 'pg_%%' and
                    rol.rolname != 'engine'
                order by
                    nsp.nspname,
                    cls.relname;

That was, as expected:

 object_schema | object_name |  owner   | object_type 
---------------+-------------+----------+-------------
 public        | fk_info_rs  | postgres | TYPE
(1 row)

And then fixing the type so that the owner was engine instead of postgres:

engine=# alter type fk_info_rs owner to engine;
ALTER TYPE

After verifying the query again:

engine=# 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_%%' and
                    cls.relname not like 'pg_%%' and
                    rol.rolname != 'engine'
                order by
                    nsp.nspname,
                    cls.relname;

With no output:

 object_schema | object_name | owner | object_type 
---------------+-------------+-------+-------------
(0 rows)

We relaunched the engine config command and everything ended smoothly.

Thanks again for the help.

Yes 

But the bug is still relevant 

This fk_info_rs TYPE which defines the fn_db_validate_fks that uses it are created by fkvalidator.sh and should be dropped afterwards 
(see that ./packaging/setup/dbutils/fkvalidator.sh has a cleanup method that is trapped and executed)

So, we must check why we have this fk_info_rs TYPE and it was not cleaned after fkvalidator.sh completes

I did not succeed to reproduce the issue.
I suppose that this may occur only by manual termination,
so the DB remains with uncleaned temporary object.

I have added CASCADE to the function DROP statement just to be on the
safe side.

Only way to try to reproduce this issue for QE :

While upgrading from oVirt 4.4.4 to 4.4.9 

1) Kill manually engine-setup
2) run engine-setup again

Tested in ovirt-engine-4.5.0.7-0.9.el8ev.noarch

Steps:
1. installed 4.4.4 engine
2. did run engine-upgrade-check - no object with postgres owner
3. interrupted engine-setup in Misc configuration (early) - no object with postgres owner
4. interrupted engine-setup in Misc configuration - no object with postgres owner
5. interrupted engine-setup in Creating/refreshing Engine 'internal' domain database schema - no object with postgres owner 
6. engine-setup - succeeded

So I did not reproduce the issue. Database user running the fkvalidator is defined by OVESETUP_DB/user and I did use the default value.
Feel free to reopen when it happens again.