Bug 1259782 - engine-setup creates a database engine_TIMESTAMP
engine-setup creates a database engine_TIMESTAMP
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.3.0
Unspecified Unspecified
medium Severity unspecified
: ovirt-4.0.0-alpha
: ---
Assigned To: Yedidyah Bar David
Pavel Stehlik
:
: 1072878 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-03 10:13 EDT by Yedidyah Bar David
Modified: 2017-03-13 16:59 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-24 05:14:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Integration
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yedidyah Bar David 2015-09-03 10:13:38 EDT
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 14:17:06 EDT
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 01:25:22 EDT
(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 15:14:02 EDT
Do what you think best, I gave reasoning of current implementation.
Comment 5 Yedidyah Bar David 2015-09-07 01:53:38 EDT
(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 03:57:41 EST
*** Bug 1072878 has been marked as a duplicate of this bug. ***
Comment 17 Yaniv Lavi (Dary) 2016-03-24 05:14:30 EDT
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.

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