Description of problem: Provisioning checks if db 'engine' exists only rather late. If possible, it should check that at validation, and show the new chosen name at the preview. Otherwise it should warn (or at least info?) that it's creating a new db/user.
(In reply to Yedidyah Bar David from comment #0) > Description of problem: > > Provisioning checks if db 'engine' exists only rather late. > > If possible, it should check that at validation, and show the new chosen > name at the preview. Otherwise it should warn (or at least info?) that it's > creating a new db/user. If user/database are renamed they are displayed in the summary.
(In reply to Alon Bar-Lev from comment #1) > (In reply to Yedidyah Bar David from comment #0) > > Description of problem: > > > > Provisioning checks if db 'engine' exists only rather late. > > > > If possible, it should check that at validation, and show the new chosen > > name at the preview. Otherwise it should warn (or at least info?) that it's > > creating a new db/user. > > If user/database are renamed they are displayed in the summary. I didn't notice that, perhaps that's the problem :-) Anyway, why not check at validation? I think it's quite misleading to say there 'engine' if we can check and know that it will be different.
(In reply to Yedidyah Bar David from comment #2) > Anyway, why not check at validation? I think it's quite misleading to say > there 'engine' if we can check and know that it will be different. I do not like we access database at all before misc... and in provisioning it is worse as we need to modify user password before we can check if database is empty, so we actually change system state, which belongs to misc.
(In reply to Alon Bar-Lev from comment #3) > (In reply to Yedidyah Bar David from comment #2) > > Anyway, why not check at validation? I think it's quite misleading to say > > there 'engine' if we can check and know that it will be different. > > I do not like we access database at all before misc... and in provisioning > it is worse as we need to modify user password before we can check if > database is empty, so we actually change system state, which belongs to misc. Very well, so warn when possible. IMO, in most if not all cases, this is an indication of a problem from the user's pov.
(In reply to Yedidyah Bar David from comment #4) > (In reply to Alon Bar-Lev from comment #3) > > (In reply to Yedidyah Bar David from comment #2) > > > Anyway, why not check at validation? I think it's quite misleading to say > > > there 'engine' if we can check and know that it will be different. > > > > I do not like we access database at all before misc... and in provisioning > > it is worse as we need to modify user password before we can check if > > database is empty, so we actually change system state, which belongs to misc. > > Very well, so warn when possible. > > IMO, in most if not all cases, this is an indication of a problem from the > user's pov. this people who use provisioning do not care what database is created, you can as well condition the summary print. what will a warning serve in this case? what is the action item? not sure these kind of discussions belongs to bugzilla.
OK, I was wrong, we connect using postgres user, so we do not need to alter state when checking if database is empty. So this can be done at validation stage if introducing complexity for the provisioning module that is now an autonomic stage. If this is to be done, it should be synced in dwh and reports. I still think that just dropping the user and database names from summary if provisioning is the simplest solution if indeed there is a problem.
Postponing to 3.6.1 not being a blocker for 3.6.0
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
*** This bug has been marked as a duplicate of bug 1259782 ***