Make the dhcp module more reusable

Without this patch large portions of the dhcpd.conf are solely under the
control of the dhcp module itself.  This is a problem for 3rd parties
like myself who want to change some of the behavior configured in this
file by these resources.

This patch fixes the problem in a non-breaking way by exposing all of
the configuration file fragments flowing into dhcpd.conf as class
parameters of the main dhcp class.  3rd parties may now override the
header using their own content like so:

    class { dhcp:
      dhcp_conf_header => template("site/my_dhcpd.conf.header")
    }

Conflicts:

	manifests/init.pp

manifests/init.pp

@@ -2,6 +2,11 @@
   $dnsdomain,
   $nameservers,
   $ntpservers,
+  $dhcp_conf_header   = 'INTERNAL_TEMPLATE',
+  $dhcp_conf_ddns     = 'INTERNAL_TEMPLATE',
+  $dhcp_conf_pxe      = 'INTERNAL_TEMPLATE',
+  $dhcp_conf_extra    = 'INTERNAL_TEMPLATE',
+  $dhcp_conf_fragments = {},
   $interfaces         = undef,
   $interface          = 'NOTSET',
   $dnsupdatekey       = undef,
@@ -30,6 +35,29 @@
     $dhcp_interfaces = $interfaces
   }
 
+  # JJM Decide where to pull the fragment content from.  Either this module, or
+  # from the end user.  This makes the module much more re-usable by 3rd
+  # parties without modifying the module itself.
+  #
+  # NOTE: These templates should be evaluated after all other local variables
+  # have been set.
+  $dhcp_conf_header_real = $dhcp_conf_header ? {
+    INTERNAL_TEMPLATE => template('dhcp/dhcpd.conf-header.erb'),
+    default           => $dhcp_conf_header,
+  }
+  $dhcp_conf_ddns_real = $dhcp_conf_ddns ? {
+    INTERNAL_TEMPLATE => template('dhcp/dhcpd.conf.ddns.erb'),
+    default           => $dhcp_conf_ddns,
+  }
+  $dhcp_conf_pxe_real = $dhcp_conf_pxe ? {
+    INTERNAL_TEMPLATE => template('dhcp/dhcpd.conf.pxe.erb'),
+    default           => $dhcp_conf_pxe,
+  }
+  $dhcp_conf_extra_real = $dhcp_conf_extra ? {
+    INTERNAL_TEMPLATE => template('dhcp/dhcpd.conf-extra.erb'),
+    default           => $dhcp_conf_extra,
+  }
+
   package { $packagename:
     ensure   => installed,
     provider => $operatingsystem ? {
@@ -60,23 +88,38 @@
   concat {  "${dhcp_dir}/dhcpd.conf": }
   concat::fragment { 'dhcp-conf-header':
     target  => "${dhcp_dir}/dhcpd.conf",
-    content => template('dhcp/dhcpd.conf-header.erb'),
+    content => $dhcp_conf_header_real,
     order   => 01,
   }
   concat::fragment { 'dhcp-conf-ddns':
     target  => "${dhcp_dir}/dhcpd.conf",
-    content => template('dhcp/dhcpd.conf.ddns.erb'),
+    content => $dhcp_conf_ddns_real,
+    order   => 10,
   }
   concat::fragment { 'dhcp-conf-pxe':
     target  => "${dhcp_dir}/dhcpd.conf",
-    content => template('dhcp/dhcpd.conf.pxe.erb'),
+    content => $dhcp_conf_pxe_real,
+    order   => 20,
   }
   concat::fragment { 'dhcp-conf-extra':
     target  => "${dhcp_dir}/dhcpd.conf",
-    content => template('dhcp/dhcpd.conf-extra.erb'),
+    content => $dhcp_conf_extra_real,
     order   => 99,
   }
 
+  # Any additional dhcpd.conf fragments the user passed in as a hash for
+  # create_resources.  This allows the end user almost total control over the
+  # DHCP server without modifying this module at all.
+
+  # JJM This is commented out because the create_resources in PE does not
+  # support the third option.
+  # $fragment_defaults = {
+  #   content => "# Managed by Puppet\n",
+  #   target  => "${dhcp_dir}/dhcpd.conf",
+  #   order   => 80,
+  # }
+  create_resources('concat::fragment', $dhcp_conf_fragments)
+
   # dhcpd.pool
   concat { "${dhcp_dir}/dhcpd.pools": }
   concat::fragment { 'dhcp-pools-header':