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

Bug 1529489

Summary: engine-cleanup fails if history database is inaccessible
Product: [oVirt] ovirt-engine-dwh Reporter: Yedidyah Bar David <didi>
Component: SetupAssignee: Yedidyah Bar David <didi>
Status: CLOSED CURRENTRELEASE QA Contact: Lucie Leistnerova <lleistne>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: bugs, lsvaty, sradco
Target Milestone: ovirt-4.2.2Flags: rule-engine: ovirt-4.2+
Target Release: 4.2.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Even if the dwh database is inaccessible, engine-cleanup can now finish successfully - but without clearing the database, obviously.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-29 11:13:27 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:
Bug Depends On:    
Bug Blocks: 1631202    

Description Yedidyah Bar David 2017-12-28 11:07:48 UTC
Description of problem:

If the dwh database is inaccessible, e.g. because the credentials were changed or because it's down/corrupted/etc., engine-cleanup fails.

It emits:

[WARNING] Cannot connect to DWH database using existing credentials: ovirt_engine_history@localhost:5432

And then:

[ ERROR ] Failed to execute stage 'Misc configuration': 'NoneType' object is not iterable

setup log has:

2017-12-28 12:54:39,743+0200 DEBUG otopi.context context._executeMethod:128 Stage misc METHOD otopi.plugins.ovirt_engine_common.ovirt_engine_dwh.db.pgpass.Plugin._misc
2017-12-28 12:54:39,744+0200 DEBUG otopi.context context._executeMethod:143 method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod
    method['method']()
  File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/ovirt-engine-dwh/db/pgpass.py", line 57, in _misc
    dbenvkeys=odwhcons.Const.DWH_DB_ENV_KEYS,
  File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 357, in createPgPass
    ':\\',
  File "/usr/lib/python2.7/site-packages/ovirt_engine/util.py", line 45, in escape
    for c in s:
TypeError: 'NoneType' object is not iterable

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

Current master, probably much before

How reproducible:
Always

Steps to Reproduce:
1. engine-setup, configure dwh
2. Change dwh db password
3. engine-cleanup

Actual results:
Fails as above

Expected results:
Succeeds

Additional info:

engine-cleanup deliberately has a code to emit the above warning instead of failing (which is what engine-setup does), but then fails later on.

This does not affect the engine database - if it's inaccessible, engine-cleanup emits a warning:

[WARNING] Cannot connect to Engine database using existing credentials: engine@localhost:5432

But then continues and finishes successfully (but without cleaning up the database).

It's not an important bug. Filing it mainly because I ran into it already several times during development, and the error message is cryptic.

Comment 1 Yedidyah Bar David 2018-02-07 08:55:02 UTC
Happened to me again, meaning verification took little time :-), so decided to fix.

Reproduction/Verification flow:

1. Install and setup ovirt+dwh
2. Stop engine, dwh, postgresql
3. Remove postgresql data directory
4. engine-cleanup

Comment 2 Lucie Leistnerova 2018-03-08 12:42:36 UTC
engine-cleanup with inaccessible database showed warning, but did not fail and database data not cleaned.

verified in ovirt-engine-setup-4.2.2.2-0.1.el7.noarch

Comment 3 Sandro Bonazzola 2018-03-29 11:13:27 UTC
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 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.