module-postgresql/manifests/server/reload.pp

# PRIVATE CLASS: do not use directly
class postgresql::server::reload {
  $service_name   = $postgresql::server::service_name
  $service_status = $postgresql::server::service_status
  $service_reload = $postgresql::server::service_reload

  exec { 'postgresql_reload':
    path        => '/usr/bin:/usr/sbin:/bin:/sbin',
    command     => $service_reload,
    onlyif      => $service_status,
    refreshonly => true,
    require     => Class['postgresql::server::service'],
  }
}
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			`# PRIVATE CLASS: do not use directly`
			`class postgresql::server::reload {`
			`$service_name = $postgresql::server::service_name`
			`$service_status = $postgresql::server::service_status`
Changes to support OpenBSD. 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. 2014-09-11 01:29:48 +02:00			`$service_reload = $postgresql::server::service_reload`
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
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			`exec { 'postgresql_reload':`
			`path => '/usr/bin:/usr/sbin:/bin:/sbin',`
Changes to support OpenBSD. 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. 2014-09-11 01:29:48 +02:00			`command => $service_reload,`
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			`onlyif => $service_status,`
			`refreshonly => true,`
			`require => Class['postgresql::server::service'],`
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			`}`
			`}`