This doesn't fix the root cause of the issue, such as the fact that
dpkg can't do wildcard removals, and the uninstall fails when you're
passing in a version number like this, but THIS test doesn't care, it
just wants to make sure the deprecation warning appears in the first
place.
This does however make the tests pass on 14.04.
Interactions between resource refreshes and the 'unless' parameter have been
fixed to follow the behaviour of the 'exec' type.
The 'unless' parameter is now always taken into account, whether in ordinary
operation, during a refresh, or when refreshonly is set to true. The resource
will not run the SQL command when the 'unless' clause matches a row.
Previously a refresh on a resource would ignore the 'unless' parameter if set
which could cause a failure re-running a command, such as attempting to create
a role that already exists.
The following examples have been fixed:
* should not run SQL when refreshed and the unless query returns rows
* with refreshonly should not run SQL when the unless query returns no rows
* with refreshonly should not run SQL when refreshed and the unless query
returns rows
This is done by moving the logic for refreshonly and whether to run the SQL
command from the provider into the type, and consolidating it in the
should_run_sql method which is called during 'command' property retrieval
(instead of sync) and during refresh.
We now test if service_ensure is 'running' or 'stopped' but it was
actually picking up the default value of ensure in params.pp which
was true, not present.
Fix this and thereby fix the failing test.
Adjusting the version is explicitly done though the postgresql::globals
class, as this affects many parts of the module. This parameter did not
function correctly on systems that did not have a default, as described
in the ticket.
At present, the ownership of pg_hba.conf is hardwired to be uid 0. It should have the same ownership as all of the other postgressql configuration files in the same cluster so that they can be managed/edited by the postgres role user (system) account.
This work converts all the tests over to beaker. Some things are
done slightly different in beaker, we rely much more heavily on
catch_failures rather than explicitly laying out the exit codes we
want but I have attempted to preserve the spirit of all tests.
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>
This allows you to set a schema search_path on postgresql_psql
resources, in case you have multiple schemas in your database and the
SQL you are trying to run requires a different path
This patch provides fixes to help tests pass on Debian. The failures were in
relation to the lack of proper removal of the server and contrib parts. Setting
the ensure => purged parameter for removal seems to have solved a lot of this.
Also, the ordering for contrib being (un)installed needed some work.
I've also made sure we use 'purged' a lot more in tests to make sure we clean
up after ourselves properly.
Signed-off-by: Ken Barber <ken@bob.sh>
This is a very very large change to the module. It started out as a fix to add
postgresl::server::config_entry, and quickly became a rewrite to fix a lot of
ordering issues inherent in the API.
Since this changes the Public API it is considered a backwards compatible
change.
See the upgrading guide in README.md for more details as to what has been
modified in this patch.
Signed-off-by: Ken Barber <ken@bob.sh>
This includes the following changes:
- Hooking up pgconf module to postgresql to manage postgresql.conf
- pgconf includes a type and provider for postgresql.conf the provider
is a simple parsed file following basic ini parsing.
- Add config_entry.pp which wraps the pgconf module.
- Replace file_line resources by postgresql::config_entry in beforeservice.pp
- Adding unit tests for the newly introduced functionality
The postgresql::role defined type was not idempotent when passed cleartext
passwords. This is because we were comparing it with its md5 equivalent in
the db.
This patch converts any cleartext passwords to md5 before comparison, but
only if they are cleartext (ie. not starting with md5).
I also bumped the version of rspec-system-puppet to get use of the refresh
method, plus did some cleanup because the old tests were a bit dusty, again
taking advantage of refresh plus changing some matchers for clarity.
Signed-off-by: Ken Barber <ken@bob.sh>
This allows non-standard users (pe-postgres) to change passwords. Also
added a function to do escaping of the password, added system tests
and rspec tests for the function.
The code to grant permissions databases and their objects has been
abstracted to `postgresql::grant` and is used by both
`postgresql::database_grant` and `postgresql::table_grant`
