Description of problem: If 3.2 was setup with a remote database user 'postgres', an upgrade to 3.3 will behave as if running a new setup. Things which already exists (database, pki) will (probably?) not be affected, but some things that happen only on upgrade from 3.2 will not happen. I did not fully analyze what this includes and what other probable implications this might have - it does include e.g. not cleaning 3.2's apache conf, not recognizing installed AIO, etc. This happens because the code that scans the 3.2 pgpass file (in plugins/ovirt-engine-setup/legacy/database.py:_init) deliberately skips lines for the user 'postgres', and if 3.2 was setup was done with 'posgres', this will be the only line, and so no lines will be parsed.
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