Bug 1049654
| Summary: | upgrade from 3.2 with remote db user 'postgres' is not recognized as an upgrade | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Yedidyah Bar David <didi> |
| Component: | ovirt-engine-setup | Assignee: | Yedidyah Bar David <didi> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | sefi litmanovich <slitmano> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.3.0 | CC: | acathrow, alonbl, bazulay, emesika, gklein, iheim, lyarwood, michele, oschreib, pablo.iranzo, pep, Rhev-m-bugs, sbonazzo, scohen, tdosek, yeylon |
| Target Milestone: | --- | ||
| Target Release: | 3.3.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | integration | ||
| Fixed In Version: | is32.1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-21 22:15:45 UTC | 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: | |||
| Bug Blocks: | 1049468, 1056111 | ||
|
Description
Yedidyah Bar David
2014-01-07 23:59:50 UTC
I the 23055 I assume that there was nothing inherently bad in using postgres, we just wanted to skip it for the local database case, in which it would be first and then the 'engine' user. I verified it only on an upgrade from a clean setup of 3.2. It might make sense to verify also on upgrades from older versions, as there were differences in what and how was kept in pgpass. The reason I think it's a blocker is that in 3.2, when user replied 'remote', the default remote db user was 'postgres', and I guess this lead many users to accept the default and use 'postgres'. We should fail installation if user is postgres asking to run the change ownership script. Eli, the script will not work correctly if target user is postgres, right? so it needs to be improved. Some options discussed: 1. Fix everything so that we continue using postgres. This includes fixing cleanup. This also means that we'll continue using it also in future upgrades, which we hoped to not need to and invested work in 3.3 for this. This is the simplest option for the user, but require more time and work - both fixing the code and testing various scenarios. 2. Just fail with some message pointing the user where to get more information about how to use another user. This will be simplest, but is unlikely to be good enough so that all of our users will be able to follow the instructions without support. 3. Create a new user as we do in a local install, change ownership to it, change the configuration to use it, and verify that it works, and if not tell the user to fix the remote pg_hba.conf file until it works. When we choose a solution, we probably want to apply it to dwh and reports as well. For reports there is bz #1049468 . I talked about this with Lee, and he said he'll try to find out how many users are expected to be affected. Lee - comments are welcome. Thanks. moving back to assigned as the current proposed fix probably breaks cleanup We verified that the solution works as expected, in normal upgrade, rollback, and cleanup. So we basically go with #1 from comment #5 - use the existing user postgres. Note that security-sensitive users that used postgres in the past might want to switch to another user, and we might want to write an article about that. But the setup code does not care, and works the same with any user. Verified. reproduction steps: 1. yum installed RHEL 6.5 with RHEVM 3.2.5 sf22.4 on a clean vm. 2. engine-setup with remote DB: user = postgres. 3. updated to 3.3 is32.1 repos and yum updated rhevm-setup 4. engine-setup - works as upgrade, succedds to upgrade with remote DB user postgres. Closing - RHEV 3.3 Released Closing - RHEV 3.3 Released |