Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1768779

Summary: /etc/ovirt-engine/engine.conf.d/10-scl-postgres.conf is double-owned
Product: [oVirt] ovirt-engine Reporter: Yedidyah Bar David <didi>
Component: Packaging.rpmAssignee: Sandro Bonazzola <sbonazzo>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Matyáš <pmatyas>
Severity: medium Docs Contact:
Priority: unspecified    
Version: futureCC: bugs, mperina, pmatyas, sbonazzo
Target Milestone: ovirt-4.4.0Flags: pm-rhel: ovirt-4.4+
sbonazzo: devel_ack+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.4.0_beta3 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-20 20:01:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yedidyah Bar David 2019-11-05 09:04:40 UTC
Description of problem:

/etc/ovirt-engine/engine.conf.d/10-scl-postgres.conf is installed by both ovirt-engine-setup-plugin-ovirt-engine-common and ovirt-engine.

I tried to come up with some flow that demonstrates a real problem, and failed. Still, it's not something that should happen, or intended.

Version-Release number of selected component (if applicable):

Since 4.2 (was called 10-scl-postgres-95.conf there).

How reproducible:

Always

Steps to Reproduce:
1. Install and setup 4.2 engine
2. rpm -qf /etc/ovirt-engine/engine.conf.d/10-scl-postgres*.conf
3. Update setup packages to 4.3
4. rpm -qf /etc/ovirt-engine/engine.conf.d/10-scl-postgres*.conf
5. engine-setup
6. rpm -qf /etc/ovirt-engine/engine.conf.d/10-scl-postgres*.conf

Actual results:

All rpm commands emit more than one package.

Expected results:

Should probably emit a single package in at least last step, preferably all of them (but we might decide this isn't an important bug to fix for older versions, if at all).

Additional info:

In practice, the engine itself does not care which PG it uses. Other tools do. Notably, I verified this flow, and it worked well:

1. Install and setup 4.2 engine
2. engine-backup --mode=backup
3. Update setup packages to 4.3
4. engine-backup --mode=backup

First backup used pg 9.5, second one used tools (pg_dump, psql) of 10. It worked well, nonetheless. Didn't try to verify restore. Perhaps restore does fail, and if so, it should be fixed and verified specifically. E.g. something like:

1. Install (do not setup) 4.2 engine.
2. Take a snapshot of the machine
3. engine-setup
5. Update setup packages to 4.3
6. engine-backup --mode=backup --file=f1
7. Copy f1 somewhere
8. Revert (or preview) the machine to the snapshot of step 2
9. copy f1 back and try to restore from it

IMO it should succeed, although that's not a very likely scenario. It might fail, though, because pg_restore of 9.5 will see the dump was taken with 10 and refuse to restore it.

Comment 1 Petr Matyáš 2019-11-19 09:30:08 UTC
*** Bug 1769677 has been marked as a duplicate of this bug. ***

Comment 2 Petr Matyáš 2019-11-19 11:36:31 UTC
(In reply to Yedidyah Bar David from comment #0)
> First backup used pg 9.5, second one used tools (pg_dump, psql) of 10. It
> worked well, nonetheless. Didn't try to verify restore. Perhaps restore does
> fail, and if so, it should be fixed and verified specifically. E.g.
> something like:
> 
> 1. Install (do not setup) 4.2 engine.
> 2. Take a snapshot of the machine
> 3. engine-setup
> 5. Update setup packages to 4.3
> 6. engine-backup --mode=backup --file=f1
> 7. Copy f1 somewhere
> 8. Revert (or preview) the machine to the snapshot of step 2
> 9. copy f1 back and try to restore from it
> 
> IMO it should succeed, although that's not a very likely scenario. It might
> fail, though, because pg_restore of 9.5 will see the dump was taken with 10
> and refuse to restore it.

This flow failed on restore with:
[root@hostname ~]# engine-backup --mode=restore --scope=all --file=backup --log=restore.log --restore-permissions --provision-all-databases
Can't read /etc/scl/conf/rh-postgresql10, rh-postgresql10 is probably not installed.
/usr/bin/engine-backup: line 1789: psql: command not found
Preparing to restore:
- Unpacking file 'backup'
Restoring:
- Files
Provisioning PostgreSQL users/databases:
- user 'engine', database 'engine'
- user 'ovirt_engine_history', database 'ovirt_engine_history'
Restoring:
/usr/bin/engine-backup: line 1789: psql: command not found
FATAL: Can't connect to database 'engine'. Please see '/usr/bin/engine-backup --help'.

I have ovirt-engine-tools-backup-4.2.8.9-0.1.el7ev.noarch

Comment 3 Sandro Bonazzola 2020-02-24 20:48:53 UTC
Martin, we are not going to use scl anymore in RHV 4.4 how do we handle backup / restore for this file?
Is the file still needed in 4.4 source tree? I see it still referenced:

./Makefile:
  641 : 	echo "sclenv=\"rh-postgresql10\"" > "$(PREFIX)/etc/ovirt-engine/engine.conf.d/10-scl-postgres.conf"
./ovirt-engine.spec.in:
 1006 : cat > "%{buildroot}%{engine_etc}/engine.conf.d/10-scl-postgres.conf" << __EOF__
 1260 : %config %{engine_etc}/engine.conf.d/10-scl-postgres.conf

Comment 4 Yedidyah Bar David 2020-02-25 11:11:45 UTC
(In reply to Sandro Bonazzola from comment #3)
> Martin, we are not going to use scl anymore in RHV 4.4 how do we handle
> backup / restore for this file?

Not sure what you mean. We still didn't start to work, AFAIU, on upgrade
from 4.3 to 4.4, right?

> Is the file still needed in 4.4 source tree? I see it still referenced:
> 
> ./Makefile:
>   641 : 	echo "sclenv=\"rh-postgresql10\"" >
> "$(PREFIX)/etc/ovirt-engine/engine.conf.d/10-scl-postgres.conf"
> ./ovirt-engine.spec.in:
>  1006 : cat > "%{buildroot}%{engine_etc}/engine.conf.d/10-scl-postgres.conf"
> << __EOF__
>  1260 : %config %{engine_etc}/engine.conf.d/10-scl-postgres.conf

In both places it's conditional, and not installed if SCL PG is not used.

So I guess SCL handling can be completely removed for now.

Eventually we might need to work on supporting upgrading to a newer PG within EL8, but this can wait. Some of the code will still be relevant, so it might be best to do nothing for now.

BTW, re the original bug, I now realized it affects identically also the file /etc/ovirt-engine/engine.conf.d/20-setup-jboss-overlay.conf . Martin - you are more than welcome to comment also on this one :-)

Comment 5 Yedidyah Bar David 2020-03-23 09:24:14 UTC
Once we remove SCL handling [1], current subject won't be relevant for 4.4 anymore.

Checked also /etc/ovirt-engine/engine.conf.d/20-setup-jboss-overlay.conf . This file contains a single line:

ENGINE_JAVA_MODULEPATH="/usr/share/ovirt-engine-wildfly-overlay/modules:${ENGINE_JAVA_MODULEPATH}"

which does not include versions and was never changed since introduction (in 4.0). So for the backup/restore flow (comment 2) it's not a problem.

So can be postponed for now, for 4.4.

Still need to decide about 4.3.

[1] https://gerrit.ovirt.org/107489

Comment 6 Sandro Bonazzola 2020-04-03 13:51:46 UTC
I think we can keep on 4.4 only then, thanks for checking didi

Comment 7 Sandro Bonazzola 2020-04-03 13:52:56 UTC
Moving to post, https://gerrit.ovirt.org/107489 is going to resolve the original issue by removing scl config file from the rpm.

Comment 8 Sandro Bonazzola 2020-04-07 14:11:19 UTC
https://gerrit.ovirt.org/#/c/107489/ has been merged

Comment 9 Petr Matyáš 2020-04-24 12:08:37 UTC
Verified on ovirt-engine-4.4.0-0.33.master.el8ev.noarch

The file is now not owned by any package, as it is not necessary and is present only because of restore from backup.

Comment 10 Sandro Bonazzola 2020-05-20 20:01:41 UTC
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020.

Since the problem described in this bug report should be
resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.