This is likely to be a controversial change so I wanted to put some
explanation of our reasoning into the commit message. This gets
kind of complex so I'll start with the problem and then the reasoning.
Problem:
We rely heavily on the ability to uninstall and reinstall postgres
throughout our testing code, testing features like "can I move from the
distribution packages to the upstream packages through the module" and
over time we've learnt that the uninstall code simply doesn't work a lot
of the time. It leaves traces of postgres behind or fails to remove
certain packages on Ubuntu, and generally causes bits to be left on your
system that you didn't expect.
When we then reinstall things fail because it's not a true clean slate,
and this causes us enormous problems during test. We've spent weeks and
months working on these tests and they simply don't hold up well across
the full range of PE platforms.
Reasoning:
Due to all these problems we've decided to take a stance on uninstalling
in general. We feel that in 2014 it's completely reasonable and normal
to have a good provisioning pipeline combined with your configuration
management and the "correct" way to uninstall a fully installed service
like postgresql is to simply reprovision the server without it in the
first place. As a general rule this is how I personally like to work
and I think is a good practice.
WAIT A MINUTE:
We understand that there are environments and situations in which it's
not easy to do that. What if you accidently deployed Postgres on
100,000 nodes? When this work is finished I'm going to take a look at
building some example 'profiles' to be found under examples/ within this
module that can uninstall postgres on popular platforms. These can be
modified and used in your specific case to uninstall postgresql. They
will be much more brute force and reliant on deleting entire directories
and require you to do more work up front in specifying where things are
installed but we think it'll prove to be a much cleaner mechanism for
this kind of thing rather than trying to weave it into the main module
logic itself.
This conversion is done by Transpec 2.3.1 with the following command:
transpec -f -c "bundle exec rake spec"
* 82 conversions
from: it { should ... }
to: it { is_expected.to ... }
* 21 conversions
from: == expected
to: eq(expected)
* 20 conversions
from: obj.should
to: expect(obj).to
* 5 conversions
from: its([:key]) { }
to: describe '[:key]' do subject { super()[:key] }; it { } end
* 1 conversion
from: it { should_not ... }
to: it { is_expected.not_to ... }
* 1 conversion
from: its(:attr) { }
to: describe '#attr' do subject { super().attr }; it { } end
For more details: https://github.com/yujinakayama/transpec#supported-conversions
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`
Previously we only created a new user, any updates to the defined resource
would not update the role. This patch adds extra logic to modify a role
whenever a parameter is changed.
System tests have also been added to support this.
The non-default tests try to set UTF8 when UTF8 is not installed on the en_US
machine. These are non-default settings anyway, but one should presume the
correct locale should be set before this is attempted, this patch includes
that step.
In an ideal world we would use a locale module to do this.
This patch also fixes an Ubuntu 10.04 issue where you need to be absolute about
the locale and encoding as well.
Signed-off-by: Ken Barber <ken@bob.sh>
This patch just adds some new tests for the unknown OS patch, and cleans up
some existing tests to look for the new warning message.
Also, change the warning message for $osfamily and manage_package_repo to
reflect the parameter at fault.
Signed-off-by: Ken Barber <ken@bob.sh>
Prior to this commit, if you attempted to use the module to
manage postgres on any OS other than Redhat/Debian, there
was an explicit check for that, and a call to `fail`.
In reality, the OS family is only used to build up defaults
for various path and package names, which are all exposed
as parameters. If the user is willing to explicitly pass
in all of those parameters, there's no reason we should
fail based on OS family.
This commit adds checks to the 'default' osfamily case
such that we now only fail if they're on a non-Redhat-or-Debian
system *and* they haven't explicitly passed in values for
all of the required parameters.
This patch ports all of the existing system tests to use rspec-system instead.
To assist with this conversion some patches were made to fix OS compatibility
where necessary. We also added an ensure parameter to the postgresql::server
class to assist with removing PostgreSQL configuration to aid with testing
cleanups.
The documentation has been updated to indicate test usage with rspec-system,
we've also renamed the 'tests' directory to 'examples'.
Signed-off-by: Ken Barber <ken@bob.sh>
Skip tests that don't apply to Centos 5, and make sure the parent directory
for tablespace correction has the correct SELinux settings for tablespace
management.
Signed-off-by: Ken Barber <ken@bob.sh>
This removes the 'include' parameter for PostgreSQL 8.1 as it was failing on
Centos 5.
Also added Centos 5 system tests using our new Vagrant boxes.
Signed-off-by: Ken Barber <ken@bob.sh>
The module file had the wrong revision in it for starters. And there was some
missing items from the .gitignore.
The extra README.md in spec/system was getting extracted as the main README
on the forge so I remove it, moving the content that was not duplicated
already into README.md.
I took the opportunity also to finish the documentation in the Reference
section of the README to make sure all classes and defined resources are
documented.
Signed-off-by: Ken Barber <ken@bob.sh>
This patch provides a more advanced way of managing pg_hba rules, by providing a
defined resource to manage a pg_hba file, and a defined resource for managing
rules within such a file (pg_hba_rule).
These new resources are wrappers around ripinaar-concat, and utilise file
assemblies instead of a template to compose the pg_hba.conf file.
I've provided a function that interprets the old ip4|6acl arrays and converts
them to this new format for backwards compatibility as well.
I slightly reformatted our documentation to allow for better documentation of
defined resources in 'Usage' as well, and provided examples of how to use this
new resource.
This hopefully should go a long way to solving the PR's related to lack of full
functionality for pg_hba.conf.
Signed-off-by: Ken Barber <ken@bob.sh>
This adds the parameter 'locale' to the 'postgresql' class so we have a global
default, and adds it two the defined resources 'postgresql::db' and
'postgresql::database'. This allows users to either:
* Defined a global default for the cluster
* Define a per-database default
As a side-effect I had to make sure 'charset' was also exposed in a similar
manner as some locales need a particular charset to work.
Tests were added to test both the 'createdb' case and 'initdb' case for Redhat,
and some refactoring was done to make the existing non_default test area use
heredocs so my manifests and test code was kept close together. As apposed to
entirely different files and places in the directory structure.
I cleaned up the related execs a little bit, adding logoutput => on_failure
where needed so we can debug failures. Beforehand execs just 'failed', but
now we should be able to get better feedback from failed execs helping support.
I also add intention comments in parts of the Puppet code that I touched where
it made sense.
Signed-off-by: Ken Barber <ken@bob.sh>
This patch includes some very basic and initial unit testing using rspec-puppet
and for the case of facts, just normal rspec.
I've taken a very light approach here as rspec-puppet can be quite combinatorial
when one gets carried away. For now I've just added basic compile failure
detection effectively for classes and defined resources. As we continue to work
on the code and find regressions this work can be expanded.
For facts and functions I've also taken a basic approach for now.
One little thing I did change, was the strange string that the fact returns
when the default version is undefined. Instead of an error message I've just
returned the string 'unknown' which is more in line with other facts I've seen
in the wild, and to be quite honest 'unknown' is fairly self-explantory. Since
a fact isn't an error reporting message this seemed more appropriate, and looked
nicer in the rspec test.
As far as travis-ci support, I've added the same configuration that @jmmcune
came up with for stdlib which is pretty light and reasonable standard now we
propogated that to 4 or so other modules in the puppetlabs/ namespace. It should
work out of the box.
Signed-off-by: Ken Barber <ken@bob.sh>
Previously we hadn't supported using the official PostgreSQL repos for deb-based
packaging. This commit fixes that by introducing the management of the apt
repositories on the host as required, and using the correct package and service
name.
Signed-off-by: Ken Barber <ken@bob.sh>
Previously the validate_db_connection defined type was trying to use inherits
like a class. This of course would fail.
After analyzing its usage, I've removed the need for the top-level params
inherit by just including the 'postgresql' module which pulls in the client
package and the params class as well. It also avoids resource duplication
for the client package as well.
To ensure we don't get regression on this I've added system tests that test
this defined type in a success and failure state.
Signed-off-by: Ken Barber <ken@bob.sh>
The GPG key for yum.postgresql.org was in the wrong directory,
and as written, would have only supported postgres 9.2 anyway.
I looked at the yum rpms for a few other versions besides 9.2,
and they appear to be using the same GPG key. So this commit
assumes that they all are doing so, and it sets things up
accordingly. Hopefully this will make the yumrepo support
compatible with other versions of postgres besides 9.2, but I
haven't added that to the actual test matrix yet.
Thanks to some tricks I learned from Nan Liu and Dan Bode, I was
able to figure out a way to move all of the new version-related stuff
back into the params class, and clean up some of the if/_real stuff.
Basic tests for centos6 + pg 9.2 are passing.
