module-postgresql/manifests/client.pp

# Install client cli tool. See README.md for more details.
class postgresql::client (
  $file_ensure    = 'file',
  $package_name   = $postgresql::params::client_package_name,
  $package_ensure = 'present'
) inherits postgresql::params {
  validate_string($package_name)

  package { 'postgresql-client':
    ensure => $package_ensure,
    name   => $package_name,
    tag    => 'postgresql',
  }

  file { '/usr/local/bin/validate_postgresql_connection.sh':
    ensure => $file_ensure,
    source => 'puppet:///modules/postgresql/validate_postgresql_connection.sh',
    owner  => 0,
    group  => 0,
    mode   => '0755',
  }

}
Major rewrite to solve order dependencies and unclear public API 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> 2013-08-27 22:43:47 +02:00			`# Install client cli tool. See README.md for more details.`
Update the base class to accept `version` parameter 2012-12-20 01:50:45 +01:00			`class postgresql::client (`
Remove the ensure => absent uninstall code. 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. 2014-07-02 16:45:07 +02:00			`$file_ensure = 'file',`
Update the base class to accept `version` parameter 2012-12-20 01:50:45 +01:00			`$package_name = $postgresql::params::client_package_name,`
			`$package_ensure = 'present'`
			`) inherits postgresql::params {`
Major rewrite to solve order dependencies and unclear public API 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> 2013-08-27 22:43:47 +02:00			`validate_string($package_name)`
Update the base class to accept `version` parameter 2012-12-20 01:50:45 +01:00
			`package { 'postgresql-client':`
Fix lint warnings 2015-01-11 05:27:57 +01:00			`ensure => $package_ensure,`
			`name => $package_name,`
			`tag => 'postgresql',`
Update the base class to accept `version` parameter 2012-12-20 01:50:45 +01:00			`}`

Remove the ensure => absent uninstall code. 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. 2014-07-02 16:45:07 +02:00			`file { '/usr/local/bin/validate_postgresql_connection.sh':`
(GH-198) Fix race condition on postgresql startup 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> 2013-10-23 23:49:16 +02:00			`ensure => $file_ensure,`
Remove the ensure => absent uninstall code. 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. 2014-07-02 16:45:07 +02:00			`source => 'puppet:///modules/postgresql/validate_postgresql_connection.sh',`
(GH-198) Fix race condition on postgresql startup 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> 2013-10-23 23:49:16 +02:00			`owner => 0,`
			`group => 0,`
Remove the ensure => absent uninstall code. 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. 2014-07-02 16:45:07 +02:00			`mode => '0755',`
(GH-198) Fix race condition on postgresql startup 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> 2013-10-23 23:49:16 +02:00			`}`

Update the base class to accept `version` parameter 2012-12-20 01:50:45 +01:00			`}`