remove apache ssl proxy in preparation of replacing it with a stunnel setup

This presents us with an interesting problem of deprecation. We need to manage
the removal of something that we previously installed in any released code. How
long we carry the puppet code that removes raises some interesting questions: do
we require that someone who deployed version 1 (where the apache ssl proxy was
deployed) of the platform upgrade first to version 2 (where we remove the apache
ssl proxy) before they upgrade to version 3 (where the apache ssl proxy removal
is no longer present) -- or do we allow people to skip versions?

1 files changed, 9 insertions, 21 deletions

diff --git a/puppet/modules/site_couchdb/manifests/apache_ssl_proxy.pp b/puppet/modules/site_couchdb/manifests/apache_ssl_proxy.pp
index 7739473e..536dd8db 100644
--- a/puppet/modules/site_couchdb/manifests/apache_ssl_proxy.pp
+++ b/puppet/modules/site_couchdb/manifests/apache_ssl_proxy.pp
@@ -1,25 +1,13 @@
-define site_couchdb::apache_ssl_proxy ($key, $cert) {
+class site_couchdb::apache_ssl_proxy {
 
-  $apache_no_default_site = true
-  include apache
-  apache::module {
-    'proxy':        ensure => present;
-    'proxy_http':   ensure => present;
-    'rewrite':      ensure => present;
-    'ssl':          ensure => present;
-  }
-  apache::vhost::file { 'couchdb_proxy': }
+# This is here to disable the previously configured apache ssl proxy
+# we were using this, but have switched to stunnel instead.
+#
+# Unfortunately, the current apache shared module doesn't handle
+# ensure=>absent, so this is going to be done the crude way, and will only
+# work for debian+derivitives, which is fine for now, but not good for the
+# future
 
-  x509::key {
-    'leap_couchdb':
-      content => $key,
-      notify  => Service[apache];
-  }
-
-  x509::cert {
-    'leap_couchdb':
-      content => $cert,
-      notify  => Service[apache];
-  }
+  package { 'apache2': ensure => absent }
 
 }