- Add missing parameter `default_connect_settings` to class `postgresql::server`
which was required by all of the classes and actually would have failed if the
tests where not masking the issue
- Remove test param that was masking the issue
Adds connection-settings (for remote DB support) when creating DB resources.
Connection-settings allows a hash of options that can be used
when connecting the a remote DB (such as PGHOST, PGPORT, PGPASSWORD
PGSSLKEY) and a special option DBVERSION indicating the version
of the remote database.
Including
- Puppet updates
- Documentation updates
- RSpec unit test updates
- RSpec acceptance test updates
- Some test coverage for connection-settings
- Working acceptance test...
Basic vagrant setup:
* Two boxes, server and client
* Runs puppet code to on server to setup a postgres server that allows all connections and md5 connections, creates db puppet to look at
* Runs puppet code on client to make a server that a psql command can be run against puppet db on other server
* Does some fancy stuff to get the fact of the IP from the first server to connect to
- Backwards compatible, with deprecation warnings around old parameters
Currently there is no resource to use for creating the recovery.conf
This resource can create a recovery.conf for replication with all
currently supported parameters
Added $service_reload parameter to params.pp, in order to allow
a reload of the postgresql server on OpenBSD, which apparently doesn't
have a service binary.
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 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.
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.
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.
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>
Most of these changes are just simple bits but I've wrapped a bunch of
stuff around 80 lines so it's slightly more readable. These should all
be no-op changes.
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>
While this worked fine in Ubuntu, it failed silently in Centos.
The script is really designed to be ran as root, so removing the user
property. This was failing our new pg_hba_rule tests without it.
Signed-off-by: Ken Barber <ken@bob.sh>
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.
Nan showed me a trick that will let us keep all of that param stuff
inside of params.pp, make it a parameterized class, and still support
the ability for users to specify a custom (non-system-default) pg
version. This commit takes the first step towards that pattern by
consolidating platform.pp and params.pp. (Everything old is new again!)
This commit creates a new class called `package_source_info`,
which has some initial framework for managing the postgresql.org
yumrepo. It also serves as a container for the 'version'
variable that is needed by the 'platform' class in order to
use other versions of postgres besides the system default.
The service provider / status stuff got a little broken during
the refactors. This should mostly fix it but there is still
one spec failing, and I will probably also refactor the
paths.pp and packages.pp into a single file together eventually.
In the exec resource to reload postgres add path parameter and set it to
"/usr/bin:/usr/sbin:/bin:/sbin", so that the service command can be
called correctly on different platforms.
notify that exec after changes to pg_hba.conf. This avoids restarting
the whole postgresql cluster for configuration changes in pg_hba.conf
which only need a reload.
