The warnings are as follows:
Warning: Scope(Concat::Fragment[pg_hba_rule_deny access to postgresql user]): The $mode parameter to concat::fragment is deprecated and has no effect
Warning: Scope(Concat::Fragment[pg_hba_rule_deny access to postgresql user]): The $owner parameter to concat::fragment is deprecated and has no effect
This commit modifies postgresql::validate_db_connection to use the
default_database parameter from postgresql::params rather than
hard-coding a local default value of "postgres".
This makes the variable consistent with the manner in which most/all of
the rest of the postgresql module currently works.
Commit also adds the new param to the README file.
E.g. pe-postgresql does NOT use postgres as the default database name.
It uses pe-postgres. So if there is no way to specify a default database
name, the postgesql::validate_db_connection resource in
postgresql::server::service will ALWAYS fail. This commit exposes the
parameter in order to avoid that situation.
Since the class is now throwing an error when you use the class directly,
I'm just removing it.
We left this in from the last rewrite as someone reported an issue a long
time ago, but alas we have been unable to prove its a problem.
Signed-off-by: Ken Barber <ken@bob.sh>
This patch is a fix for the race condition that keeps occuring during
postgresql setup. Its very rare on its own, but when you are using this
module in a CI environment it happens quite frequently.
Basically what happens is that sometimes the service will announce the
database has started, but really it is still working in the background.
Sometimes the unix socket may not be listening, and sometimes the
system is still loading and you get a weird client error.
The fix itself is a modification to postgresql::validate_db_connection
so that it is able to connect on the local unix socket, plus retry
until the database is available.
This new and improved validate_db_connection can then be put into the
build pipeline (in the service class in particular) to ensure the
database is started before continuing on with the remaining steps.
This in effect blocks the puppet module from continuing until the
postgresql database is fully started and able to receive connections
which is perfect.
Tests and documentation provided.
Signed-off-by: Ken Barber <ken@bob.sh>
