Bug 920565
| Summary: | Installer setup should ensure correct (utf8) default DB encoding | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Eli Mesika <emesika> | ||||||||||||||
| Component: | ovirt-engine-setup | Assignee: | Alex Lourie <alourie> | ||||||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Pavel Novotny <pnovotny> | ||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||
| Priority: | high | ||||||||||||||||
| Version: | 3.2.0 | CC: | acathrow, alourie, bazulay, dyasny, eedri, emesika, iheim, mgoldboi, oramraz, perobins, pnovotny, Rhev-m-bugs, sgrinber, ykaul | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Target Release: | 3.2.0 | ||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||
| OS: | Unspecified | ||||||||||||||||
| Whiteboard: | integration | ||||||||||||||||
| Fixed In Version: | sf17 | Doc Type: | Bug Fix | ||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | Type: | Bug | |||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
| Embargoed: | |||||||||||||||||
| Bug Depends On: | 919173, 1223957 | ||||||||||||||||
| Bug Blocks: | 966721 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Eli Mesika
2013-03-12 11:20:22 UTC
Can you please provide information what is the expected behaviour of this fix? * Should it change the encoding of "template1" to UTF8 always as mentioned in comment #0 or should it ask user for input as mentioned in comment #3? * Does it apply for local and remote DB or just for one of them? Thanks @Pavel This is effective during setup flows. If you provide a DB with a template1 encoding other than UTF8, the setup should stop. I got mixed results when verifying this: Checking of the DB enconding is done only if remote DB is used during installation (see attachment 'rhevm-install-remote-db.txt'). With local DB the check is not done and installation continues normally and doesn't stop (attachment 'rhevm-install-local-db.txt'). However, the 'engine' database is created with UTF8 encoding (which is right) even if 'template1' has SQL_ASCII. @Alex, Is this the desired behaviour? Or should the setup stop in every situation, i.e., also when local DB is used? Created attachment 752554 [details]
rhevm-install-remote-db.txt
Created attachment 752557 [details]
rhevm-install-local-db.txt
@Pavel It is correct that the encoding is only checked on remote DB flows. The outcome is definitely OK. But I don't understand why did the 'engine' DB creation on local installation was successful - is the template1 DB not defined as a template? Can you send me the setup logs? In our tests such a case would fail. Additionally, on local installations the DB server is reset, so template1 DB should be in UTF8. (In reply to Alex Lourie from comment #10) > @Pavel > > It is correct that the encoding is only checked on remote DB flows. > > The outcome is definitely OK. But I don't understand why did the 'engine' DB > creation on local installation was successful - is the template1 DB not > defined as a template? Can you send me the setup logs? > > In our tests such a case would fail. Additionally, on local installations > the DB server is reset, so template1 DB should be in UTF8. The template1 DB encoding was changed via recreating the DB, i.e., data dump; dropdb; createdb --encoding=SQL_ASCII; data restore (steps attached as db-template1-encoding-change.txt). I admit this may not be the best way how to provide the template1 DB with different encoding. So I repeated the verification from scratch with clean environment. Steps: 1) Prerequisite: Have a RHEL 6.4 machine without having RHEVM or Postgres server installed. 2) In /etc/sysconfig/i18n file set LANG="C". This later causes Postgres to determine the DB encoding as SQL_ASCII. 3) Reboot. 4) run 'yum install rhevm' and then 'rhevm-setup' (attachement rhevm-install-local-db-ascii.txt). Install logs are attached. The result is that 'engine' DB was created as UTF8 while all other DBs have SQL_ASCII encoding (including template1). The answers are in the DB install script /usr/share/ovirt-engine/dbscripts/create_db.sh, line 52: createdb --username=${USERNAME} --host=${SERVERNAME} --port=${PORT} ${DATABASE} -e -E UTF8 --lc-collate en_US.UTF8 --lc-ctype en_US.UTF8 -T template0 > /dev/null The DB is created always from *template0* template and with UTF8 encoding. So the role of template1 DB doesn't come into play at all. Created attachment 753627 [details]
manual change of template1 DB encoding
Created attachment 753629 [details]
RHEVM installation with clean environment and ASCII system encoding set
Created attachment 753632 [details]
RHEVM install log
Created attachment 753633 [details]
RHEVM DB install log
Verification failed in rhevm-3.2.0-11.28.el6ev (sf17.1). The results are ok only with external DB where installation stops if DB encoding is different than UTF8. With local DB installation there are mixed results: 1) correct result: even if the DB server has different encoding than UTF8, the 'engine' DB is correctly created as UTF8 2) incorrect result: local DB server with different encoding should be reset to UTF8 (including template1 DB) - this requirement is not met After the clarification in comment #19, this bug is verified - rhevm-3.2.0-11.28.el6ev (sf17.1). (In reply to Pavel Novotny from comment #22) > After the clarification in comment #19, this bug is verified - > rhevm-3.2.0-11.28.el6ev (sf17.1). Summarizing the final verification (as the above mentioned comment #19 is private): * for remote DB: installation should stop when DB has different encoding than UTF8 * for local DB: 'engine' DB must be created with UTF8 encoding no matter what encoding the local DB server has 3.2 has been released 3.2 has been released |