This allows you to use `postgres_pqsl` commands to be run against a specified host. The ultimate goal being that you can use `puppetlabs-postsgresql` to run against remote instances, especially things such as Amazons RDS service.
This PR will be further extended to do things like allow remote `table_grant` and the like.
The change introduced in b781849882 added
a complex operation that was not handled correctly for all operating
systems. This fix includes the following corrections:
- Change the systemd config and reload systemd for datadir changes in
RHEL 7, and move configuration for this into
postgresql::server::config since it is managing both the PGDATA and
PGPORT variables
- Make sure Debian systems stop the service before changing the datadir
- Recreate cert links after running initdb in Debian and early ubuntu
- Change the port in the port spec to avoid selinux issues
- Turn off selinux in pgdata spec to avoid selinux issues
- Correct syntax for describing presence of a directory in pgdata spec
- Move the pgdata spec to the end of the tests so that puppet doesn't
have to manager purging and recreating the original datadir
- Update README to describe all caveats of using this parameter
Ensure that data_directory is set in the config. per GitHub user tbd - PR#510 / PR#494 that was filed against wrong module branch"
Adds acceptance test for non default PGDATA, based on alternative_port_spec.rb
Fixes unit test for data directory
I'd like to see this patch included ASAP -- the desirable default could
be manage_pg_ident_conf => true, but one could already manage this file
manually : we don't want to wipe it.
Please switch the default from false to true at the next major release
and write a line about this in the release notes.
This defined type helps create database schemas, and assign them to an
`owner`. It is closely modeled after Postgresql::Server::Tablespace.
It uses PostgreSQL's builtin IF NOT EXISTS to guarantee idempotency.
(>= 9.3, else it checks pg_namespace).
n.b.: This defined type *requires* that a `db` is passed. This is a
concious design decision, since we find it rather useless to create such
schemas in the default `postgres` database, and if *were* useful, one
can always "over-specify".
This addresses MODULES-1098.
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
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.
