Issue 2909 - Allow for adjusting the location of $hgweb::templates

modules/hgweb/manifests/init.pp

 # == Class: hgweb
 #
 # A hgweb server setup.
 #
 # === Parameters:
 #
 # [*domain*]
 #   The auhority part of the URL the instance is associated with.
 #
 # [*is_default*]
@@ skipping 16 matching lines @@
 #   class {'hgweb':
 #     domain => 'localhost',
 #   }
 #
 class hgweb(
   $domain,
   $is_default = false,
   $certificate = hiera('hgweb::certificate', 'undef'),
   $private_key = hiera('hgweb::private_key', 'undef'),
   $hgaccess = 'puppet:///modules/hgweb/hgaccess',
+  $templates = hiera('hgweb::templates', '/usr/share/mercurial/templates'),

[Wladimir Palant, 2015/08/24 18:37:02]

I might have said this before but I'm no fan of adding configurability for the
sake of configurability. Configuration options always add a cost, and be it
losing code locality like in this case. Why does this path have to be
configured? The mercurial-common package is being installed right below, and we
*know* its template path - no need for configuring.

The real problem here is that this configuration isn't what's currently running
on our server. That's what needs fixing, ASAP.

[mathias, 2015/08/24 19:03:08]

Me neither.
Exactly. There is no need to configure the module if one does not temper with
the Mercurial installation. It behaves properly by default.
You're right again. But you seem to confuse not being informed about the
rationale with being confronted with naive code. Thus below please find some
information on why I chose this approach:

There is no need for tweaking the system Mercurial packages implied within the
hgweb module whatsoever. This module runs from scratch, requires just a domain
name to be considered setup properly. Everything else is a feature we've added
because of a specific requirement.

Now the entire repository management itself has not been integrated with Puppet
yet (and maybe never will be, that depends on whether there's enough demand, of
course). Thus everything beyond the server setup is done by those who have
access to it. This includes not only the repository administration, but also the
synchronization. And the latter is the sole reason for using a custom Mercurial.

I do not see any reason for moving this specific detail to the hgweb module. At
least not yet, primarily because doing this properly requires integrating the
repository administration as well. And this requires time I do not have.
Remember that this is an intermediate project I suggested because of our urge to
setup the Git sync properly. 

Furthermore, it's quite possible that we decide to e.g. improve on the server2
setup, which features it's own hgweb setup - without any Git stuff - and may
thus become a great opportunity to re-use the module as-is.

To make a long story short: I am convinced that the approach I've suggested is
both reasonable and lightweight. I am not convinced that it's worth the effort
of writing down to be honest, but it seems like it's still necessary.

 ) {
 
   include ssh, nginx
 
   $required_packages = ['mercurial-common', 'python-flup', 'spawn-fcgi']
   ensure_packages($required_packages)
 
   class {'sitescripts':
     sitescriptsini_content => template('hgweb/sitescripts.ini.erb'),
   }
@@ skipping 114 matching lines @@
     pattern => 'hgweb.fcgi',
     require => File['/etc/init.d/hgweb'],
     subscribe => File['/etc/hgweb.ini'],
   }
 
   nginx::hostconfig {$domain:
     certificate => $certificate ? {
       'undef' => undef,
       default => $certificate,
     },
-    source => 'puppet:///modules/hgweb/nginx.conf',
+    content => template('hgweb/nginx.conf.erb'),
     is_default => $is_default,
     log => 'access_log_hg',
     private_key => $private_key ? {
       'undef' => undef,
       default => $private_key,
     },
   }
 }