Empty require/before relationships in the server extension package
resource are changed from undef to empty arrays to work around PUP-6385
in Puppet 4.5.x. Previously undef was passed literally through
create_resources() causing Puppet to fail to find the resource named
`undef`.
- 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
On current amazon linux ami (details below), and open puppet (details below), the postgres module (installed as part of puppetlabs/puppetdb) currently, tries to start postgressql server with /etc/init.d/postgresql9.4 , while the init script doesn't have the dot in the version number, so it needs to use /etc/init.d/postgresql94
From what I see in all available postgresql server rpms, currently on amazon linux ami, seems all the init scripts of postgresql doesn't have a dot in the suffix version number.
Supporting info:
[root@puppet ~]# yum list postgres* | grep 'server\.';
postgresql94-server.x86_64 9.4.5-1.63.amzn1 @amzn-updates
postgresql8-server.x86_64 8.4.20-4.51.amzn1 amzn-updates
postgresql92-server.x86_64 9.2.14-1.56.amzn1 amzn-updates
postgresql93-server.x86_64 9.3.10-1.60.amzn1 amzn-updates
for i in postgresql8-server.x86_64 postgresql92-server.x86_64 postgresql93-server.x86_64 postgresql94-server.x86_64; do echo $i; repoquery -l $i | grep init.d; done
postgresql8-server.x86_64
/etc/rc.d/init.d/postgresql
postgresql92-server.x86_64
/etc/rc.d/init.d/postgresql92
postgresql93-server.x86_64
/etc/rc.d/init.d/postgresql93
postgresql94-server.x86_64
[root@puppet ~]# puppet --version
4.3.2
[root@puppet ~]# rpm -qa | grep puppet | grep server
puppetserver-2.2.1-1.el6.noarch
[root@puppet ~]#
[root@puppet ~]# cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2015.09"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2015.09"
PRETTY_NAME="Amazon Linux AMI 2015.09"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2015.09:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"
[root@puppet ~]#
[root@puppet ~]# cat /etc/system-release
Amazon Linux AMI release 2015.09
The `$service_provider` variable in params.pp is user-definable via `postgresql::globals::service_provider`. Thus params.pp should reference that variable correctly, like other variables from globals.pp.
Prior to this commit, when creating databases with a name or owner that has
characters which must be quoted (e.g., "pe-postgres"), the postgresql::server::database define
fails due to a SQL syntax error.
When using a database name that contains dashes or underscores, the
CREATE DATABASE statement fails with a syntax error. Use double quotes
around the database name to solve this.
This adds the ability to define the extension name separately from the
"title" of the resource, which allows you to add the extension to more
than one database.
As per the original ticket, extensions in postgresql can be defined on
a per database basis. By using the same name for both the extension and
the instance of postgresql::server::extension, you're getting duplicates
errors if you try to assign an extension to more than one database
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
inheriting postgresql::params creates a cycle, because postgresql::repo gets instantiated in postgresql::globals which is inherited by postgresql::params. Also postgresql::params are not needed, because only version is used by postgresql::repo, postgresql::repo::yum_postgresql_org and postgresql::repo::apt_postgresql_org and it get set in postgresql::globals by a resource like class instantiation.
