Bug 1259782

Summary: engine-setup creates a database engine_TIMESTAMP
Product: Red Hat Enterprise Virtualization Manager Reporter: Yedidyah Bar David <didi>
Component: ovirt-engineAssignee: Yedidyah Bar David <didi>
Status: CLOSED WONTFIX QA Contact: Pavel Stehlik <pstehlik>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 3.3.0CC: bazulay, didi, gklein, iheim, lsurette, rbalakri, Rhev-m-bugs, sbonazzo, yeylon, ykaul, ylavi
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-24 09:14:30 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 2015-09-03 14:13:38 UTC
Description of problem:

If engine-setup is requested (which is the default) to automatically provision databases, and the databases exist and non-empty, it silently creates others with a different name (adding _TIMESTAMP).

We handle this only during a rather late stage, after asking all the questions and starting the actual setup. Thus we can't (or do not want to) ask the user about this. This is because normally on a clean system postgres is not initialized yet at the customization stage.

If we did create a base_TIMESTAMP database, we emit this in the end as a note to the user.

Not sure why we do that. I never saw a case where this happened and was expected or wanted, and I did see several cases where this was not wanted but also not noticed (or noticed much later).

IMO we should just abort in such a case. Users that want multiple databases on the same system and have them created by engine-setup, will have to supply an answer file with the requested names (named base_TIMESTAMP or any other name).

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

3.3

How reproducible:

Always

Steps to Reproduce:
1. Create a database 'engine' and some table in it
2. engine-setup, choose to automatically create a database

Actual results:

engine-setup creates a database engine_TIMESTAMP (e.g. engine_20150903112339)

Expected results:

engine-setup aborts, saying database 'engine' exists.

Additional info:

Comment 2 Alon Bar-Lev 2015-09-03 18:17:06 UTC
1. this should be opened upstream not downstream, we have only one product, this behaviour is not downstream specific.
2. we minimize questions - the name of database should not be important if we provision.
3. database name can always changed later if actually required.
4. the above was the reason for this behavior.

Comment 3 Yedidyah Bar David 2015-09-06 05:25:22 UTC
(In reply to Alon Bar-Lev from comment #2)
> 1. this should be opened upstream not downstream, we have only one product,
> this behaviour is not downstream specific.
> 2. we minimize questions - the name of database should not be important if
> we provision.

If we default to 'engine' and 'engine' exists and non-empty, imo
we should not continue silently with a different name.

IMO (and not only mine), in almost all such cases, this was a result of a bug and/or user error, almost never a conscious decision/will.

> 3. database name can always changed later if actually required.
> 4. the above was the reason for this behavior.

Was this discussed anywhere? Is this documented anywhere? Do we have a bug/RFE asking this?

Comment 4 Alon Bar-Lev 2015-09-06 19:14:02 UTC
Do what you think best, I gave reasoning of current implementation.

Comment 5 Yedidyah Bar David 2015-09-07 05:53:38 UTC
(In reply to Alon Bar-Lev from comment #4)
> Do what you think best,

Very well.

> I gave reasoning of current implementation.

Thanks for that!

Comment 9 Yedidyah Bar David 2016-01-27 08:57:41 UTC
*** Bug 1072878 has been marked as a duplicate of this bug. ***

Comment 17 Yaniv Lavi 2016-03-24 09:14:30 UTC
This is by design and the summary contains the new db name. If the user chose automatic and confirmed the summary, we should not block this.