Bug 1070844

Created attachment 868584 [details]
log

In 3.4+ (and 3.3+ for engine), we use the existing database/user if all of the following are true:
1. A database with the expected name exists
2. A user with the expected name exists
3. This database is empty

The problem causing this bug is that the default names changed between 3.3 and 3.4. DB name remained ovirt_engine_history in both, but db user changed from 'engine_history' in 3.3 to 'ovirt_engine_history'.

Same is for Reports (bug #1070857), only a bit more complex (differences between 3.3 and 3.4 and also between upstream and downstream in 3.3).

I can think of several different ways to continue:
1. Do nothing and CLOSE NOTABUG. I think that's the best option. I do not understand why this is even a bug. If anyone (e.g. automated testing) needs a stable db name on setup, they should simply drop the database before a clean setup (or perhaps better yet, stop postgres and clean up /var/lib/pgsql/data).
2. Change the code to do more complex things (such as checking only db and create user if needed, whatever).
3. Change the defaults to be compatible with 3.3. To do this completely will require a difference between upstream and downstream.

Opinions?

(In reply to Yedidyah Bar David from comment #4)

> I can think of several different ways to continue:
> 1. Do nothing and CLOSE NOTABUG. I think that's the best option. I do not
> understand why this is even a bug. If anyone (e.g. automated testing) needs
> a stable db name on setup, they should simply drop the database before a
> clean setup (or perhaps better yet, stop postgres and clean up
> /var/lib/pgsql/data).

I agree, I think that's best option for me too.

(In reply to Sandro Bonazzola from comment #5)
> (In reply to Yedidyah Bar David from comment #4)
> 
> > I can think of several different ways to continue:
> > 1. Do nothing and CLOSE NOTABUG. I think that's the best option. I do not
> > understand why this is even a bug. If anyone (e.g. automated testing) needs
> > a stable db name on setup, they should simply drop the database before a
> > clean setup (or perhaps better yet, stop postgres and clean up
> > /var/lib/pgsql/data).

And/Or supply in your answer file whatever db/user name you want, if you care.

> 
> I agree, I think that's best option for me too.

Pavel, can you reply if this approach still blocks you from fixing the dwh job?

(In reply to Yedidyah Bar David from comment #6)
> (In reply to Sandro Bonazzola from comment #5)
> > (In reply to Yedidyah Bar David from comment #4)
> > 
> > > I can think of several different ways to continue:
> > > 1. Do nothing and CLOSE NOTABUG. I think that's the best option. I do not
> > > understand why this is even a bug. If anyone (e.g. automated testing) needs
> > > a stable db name on setup, they should simply drop the database before a
> > > clean setup (or perhaps better yet, stop postgres and clean up
> > > /var/lib/pgsql/data).
> 
> And/Or supply in your answer file whatever db/user name you want, if you
> care.

Just to clarify - you can't do that (I think) with automatic provisioning - you have to make sure the user/db exist and supply all credentials as if you chose 'manual'.

Just a note - if provisioning created a database with a different name than the default, setup will emit something like this in the end:

                'DWH database resources:\n'
                '    Database name:      {database}\n'
                '    Database user name: {user}\n'

Yaniv suggested (in private) that we might make this a warning, not sure about that. He also asked about showing this earlier, before end of validation. Doing this will make setup needlessly (imho, at least) significantly more complex.

(In reply to Yedidyah Bar David from comment #9)
> Just a note - if provisioning created a database with a different name than
> the default, setup will emit something like this in the end:
> 
>                 'DWH database resources:\n'
>                 '    Database name:      {database}\n'
>                 '    Database user name: {user}\n'
> 
> Yaniv suggested (in private) that we might make this a warning, not sure
> about that. He also asked about showing this earlier, before end of
> validation. Doing this will make setup needlessly (imho, at least)
> significantly more complex.

What you are suggesting here is not helping in any way.
If this is done at the end of setup the user can't do anything about it and it doesn't help in ending up with the default db name and user. Please reconsider alternatives.



Yaniv

(In reply to Yaniv Dary from comment #10)
> What you are suggesting here is not helping in any way.
> If this is done at the end of setup the user can't do anything about it and
> it doesn't help in ending up with the default db name and user. Please
> reconsider alternatives.

Suppose that we want this:
3.3 engine/dwh setup
upgrade engine/dwh to 3.4
cleanup
setup - and want to have db and user name be the default ones

There is a very simple way to make this work - just make the defaults in 3.4 either the same as in 3.3 (a bit tricky in Reports), or make both db and user name different (ugly because upstream is already released). Or change the code - and then please define very clearly what you want in such a case.

Regarding alerting earlier: the main issue I see with doing that is that we might need to change pg_hba.conf and restart postgresql in order to check if db/user exist, and we generally try not to do such changes at an early stage.

Another obvious solution is change the code to ignore the existence of the user - if db exists and empty, use it, and do whatever that's needed with the user.

The reason we do not do that currently, is that even a slight change from what we expect after a successful cleanup, might imply that user and/or db are in use by something else, and so we say 'better safe than sorry' and create new ones.

Pavel/Tareq, I suggesting removing this from automation and make adjustments per Didi's option 1 in comment #4