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.
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.
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 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 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>
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 new changelog notes for the next release. It also does some
cleanup:
* Move CHANGELOG.md to Changelog so it gets rendered in the forge
* Fix LICENSE so only the necessary boiler plate gets displayed in the Forge
And finally it increments the Modulefile version to 2.1.0.
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>
Modify params.pp to abstract the package name for the postgresql JDBC
connector and add Class['postgresql::java']. Also update the README.md
to mention the availability of this class.
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>
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
This commit provides a working implementation of a ruby
type/provider (`postgresql_psql` for handling the PSQL
commands. This is a little more flexible than doing it
via Exec resources, which is what the `postgresql::psql`
type was doing.
The old type is still present but now includes a
deprecation notification, and all of the other types
that were using the `::psql` type have been ported over
to use the `postgresql_psql` type instead.
Prior to this commit, Inkling Systems was responsible for improving
and maintaining this module. The maintainer has moved on and Inkling
wished for Puppet Labs to continue with this modules maintenance.
This commit adjusts the README and Modulefile for this change in
ownership.
I had some issues trying to connect to the server, managed with
defaults:
vagrant@precise32:~$ psql
psql: FATAL: role "vagrant" does not exist
vagrant@precise32:~$ psql -U postgres
psql: FATAL: Peer authentication failed for user "postgres"
vagrant@precise32:~$ psql -U postgres -h 127.0.0.1
psql: FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL on
FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL off
vagrant@precise32:~$ psql -U postgres -h /var/run/postgresql
psql: FATAL: Peer authentication failed for user "postgres"
After some trial and error I found out that the reasons for this was
restrictive permissions on the unix socket (which isn't bad at all):
vagrant@precise32:~$ ls -l /var/run/postgresql/
total 4
-rw------- 1 postgres postgres 5 Oct 16 20:16 9.1-main.pid
So I though I send some usage examples to help noops like myself to a
quicker start with your module :-)
