Docs update. There will be a lot of these.

docs/advanced/dynamic.md

@@ -2,6 +2,15 @@
 
 If you set the value `dynamic_config: true` in your `common.yaml`, you can use ERb syntax in your configuration values. For example, if you want to dynamically specify the location of a file from an environment variable, you could enable the `environment` plugin and do something like this:
 
-`target: <%= env_target %>` 
+```erb
+---
+data_sources: [ 'file' , 'environment' ]
+template_sources: [ 'file' ]
+dynamic_config: true
+environments:
+	development:
+		example.erb:
+  			target: <%= env_target %>
+```  			
 
 And then pass the `target` environment variable at run-time. You can also call [helper modules](../developers.md#helper-modules) to populate values as well.

docs/advanced/exec_on_write.md

@@ -1 +1,27 @@
-# Running commands per-template
+# Running commands per-template
+
+In addition to running a daemon process after the configuration files have been generated (using the `exec:` [parameter](../general/configuration.md#exec)), you can also specify a separate `exec_on_write:` parameter for each template in the `target_values` block. For example, to create a file after a template has been created you can do something like this:
+
+```yaml
+---
+exec: [ "/usr/sbin/some_daemon" ]
+data_sources: [ "file" ]
+template_sources: [ "file" ]
+
+environments:
+  development:
+    test.erb:
+      target: test.txt
+      exec_on_write: ["touch" , "/tmp/exec_on_write.tmp"]
+      config:
+        ...
+        ... rest of configuration snipped ...
+        ...
+```
+
+If these are long-running processes, Tiller will also wait for them to complete before exiting, and will also propogate signals such as SIGINT to them. 
+
+However, if you are considering using this feature to spawn additional daemons do consider that Tiller is not intended as a full-blown supervisor/init system. You may want to consider using something like [supervisord](http://supervisord.org) instead. Using Tiller to generate configuration files for multiple processes and then running supervisord through the `exec` parameter is a common use-case.
+
+## Checksums
+This feature interacts with the [checksum](checksums.md) feature: When checksums are enabled, if the template has not been written to disk, no `exec_on_write` process will be run. 

docs/advanced/separate_config.md

@@ -1,6 +1,8 @@
 # Separate configuration files per environment
 
-Instead of placing all your environment configuration in `common.yaml`, you can split environment definitions out into separate files. This was the default behaviour of Tiller < 0.7.0, although it  will remain supported in future versions. To do this, create a `/etc/tiller/environments` directory, and then a yaml file named after your environment. 
+When using the [file](../plugins/file.md) plugin, instead of placing all your environment configuration in `common.yaml` you can split environment definitions out into separate files. 
+
+This was the default behaviour of Tiller < 0.7.0, although it  will remain supported in future versions. To do this, create a `/etc/tiller/environments` directory, and then a yaml file named after your environment. 
 
 For example, consider a `/etc/tiller/common.yaml` that had a block like this:
 

docs/developers.md

@@ -4,7 +4,7 @@ Tiller follows a fairly standard gem project layout and has a Rakefile, Gemfile
 
 ## Setup
 
-To get started, ensure you have Ruby > 1.9 and the Bundler gem installed. Then run `bundle install` in the top-level directory to install all the development dependencies. You should see something similar to the following:
+To get started, ensure you have Ruby > 1.9 (Ruby 2.x is preferred as some plugins require it) and the Bundler gem installed. Then run `bundle install` in the top-level directory to install all the development dependencies. You should see something similar to the following:
 
 	Using rake 10.4.2
 	Using ffi 1.9.10
@@ -20,29 +20,30 @@ To get started, ensure you have Ruby > 1.9 and the Bundler gem installed. Then r
 You can now use the Rake tasks (through `bundle exec`)to build the gem :
 
 	$ bundle exec rake build
-	tiller 0.6.5 built to pkg/tiller-0.6.5.gem.
+	tiller 1.0.0 built to pkg/tiller-1.0.0.gem.
 
 And then install the locally produced package :
 
 	$ bundle exec rake install:local
-	tiller 0.6.5 built to pkg/tiller-0.6.5.gem.
-	tiller (0.6.5) installed.
+	tiller 1.0.0 built to pkg/tiller-1.0.0.gem.
+	tiller (1.0.0) installed.
 
 I recommend Bundler version 1.10.6 or later; older versions may not have the 'install:local' job available.
 
 ## Tests
 
 There are quite a few tests under the `features/` directory which use Cucumber and Aruba. Again, you can run these through a Rake task :
-
-	$ bundle exec rake features
-	Feature: Defaults module
-	...
-	... Rest of output snipped
-	...
-	22 scenarios (22 passed)
-	70 steps (70 passed)
-	0m6.500s
-
+```
+$ bundle exec rake features
+Feature: Defaults module
+...
+... Rest of output snipped
+...
+110 scenarios (110 passed)
+588 steps (588 passed)
+0m49.460s
+```
+
 `bundle exec rake` with no arguments will by default build the gem, install it and then run the tests. You can see the status of builds across all branches of this gem at [https://travis-ci.org/](https://travis-ci.org/markround/tiller/branches) - these are run everytime I push to a origin branch on Github.
 
 ## Contributions

docs/general/configuration.md

@@ -42,6 +42,13 @@ This parameter specifies which plugin will be providing the templates. It uses t
 template_sources: [ "file" ]
 ```
 
+** IMPORTANT NOTE ** : The order in which you specify plugins is important. Plugins will be loaded in the order they are specified, so in the following example, values from the environment will take precedence over anything specified in `common.yaml` from the [file](../plugins/file.md) plugin, and templates from [Consul](../plugins/consul.md) will take precedence over anything from the filesystem:
+
+```yaml
+data_sources: [ "file" , "environment" ]
+template_sources: [ "file" , "consul" ]
+```
+
 
 ## default_environment
 
@@ -52,7 +59,7 @@ default_environment: testing
 ```
 
 # Example
-For a simple use-case where you're just generating everything from files and then spawning MongoDB with a different replica set name specified in the staging and production environments, you'd have a common.yaml like this:
+For a simple use-case where you're just generating everything from [files](../plugins/file.md) and then spawning MongoDB with a different replica set name specified in the staging and production environments, you'd have a common.yaml like this:
 
 ```yaml
 ---

docs/general/thanks.md

@@ -1,3 +1,5 @@
 # Thanks
 
-Thanks to everyone who has submitted bug reports and feature requests. Also a special mention and huge thanks to JetBrains, for providing me with a free [opensource project license](https://www.jetbrains.com/buy/opensource/) for the fantastic [RubyMine](https://www.jetbrains.com/ruby/) IDE!
+Thanks to everyone who has submitted bug reports and feature requests. Also a special mention and huge thanks to JetBrains, for providing me with a free [opensource project license](https://www.jetbrains.com/buy/opensource/) for the fantastic [RubyMine](https://www.jetbrains.com/ruby/) IDE!
+
+And of course, the biggest thanks and love go to my wonderful wife for all her support and for putting up with my late-night brain "fizzing" when I'm pondering new features or thinking in Ruby :)

docs/plugins/consul.md

@@ -23,7 +23,7 @@ The above example would use templates from files, and retrieve values from Consu
 
 
 # Configuring
-Configuration for this plugin is placed inside a "consul" block. This should be in the the top-level of `common.yaml` file, or in a per-environment block. See the main [README.md](https://github.com/markround/tiller/blob/master/README.md#common-configuration) for more information on this.
+Configuration for this plugin is placed inside a "consul" block. This should be in the the top-level of `common.yaml` file, or in a [per-environment block](file.md#overriding-common-settings).
 
 A sample configuration (showing the defaults for most parameters) is as follows :
 
@@ -177,5 +177,5 @@ ServicePort : <%= consul_services['consul'][0].ServicePort %>
 ```
 
 # Further reading
-See [this](http://www.markround.com/blog/2016/05/12/new-consul-plugin-for-tiller) blog post for an introduction to this plugin with some examples.
+See [this](http://www.markround.com/blog/2016/05/12/new-consul-plugin-for-tiller) blog post for a walk-through tutorial with some examples.
 

docs/plugins/defaults.md

@@ -1,5 +1,5 @@
 # Defaults Plugin
-If you add `  - defaults` to your list of data sources in `common.yaml`, you'll be able to make use of default values for your templates, which can save a lot of repeated definitions if you have a lot of common values shared between environments. You can also (as of Tiller 0.7.3) use it to install a template across all environments.
+If you add `defaults` to your list of data sources in `common.yaml`, you'll be able to make use of default values for your templates, which can save a lot of repeated definitions if you have a lot of common values shared between environments. You can also use it to install a template across all environments.
 
 These defaults are sourced from a `defaults:` block in your `common.yaml`, or from `/etc/tiller/defaults.yaml` if you are using the old-style configuration. For both styles, any individual `.yaml` files under `/etc/tiller/defaults.d/` are also loaded and parsed.
 
@@ -22,7 +22,7 @@ This would make the variable `domain_name` available to all templates, and would
 
 ## Defaults per environment
 
-As of Tiller 0.7.7, you can also use the file datasource to specify a top-level `global_values:` key inside each environment block to specify global values unique to that environment. See [issue #18](https://github.com/markround/tiller/issues/18) for the details.
+You can also use the file datasource to specify a top-level `global_values:` key inside each environment block to specify global values unique to that environment. See [issue #18](https://github.com/markround/tiller/issues/18) for the details.
 
 This means you can (optionally) use the defaults datasource to specify a default across _all_ environments, `global_values:` for defaults specific to each environment, and optionally over-write them with local `config:` values on each template. Something like this :
 

docs/plugins/http.md

@@ -9,20 +9,16 @@ The plugins expect data to be returned in JSON format, apart from the template c
 Add the `http` plugins in your `common.yaml`, e.g.
 
 ```yaml
-data_sources:
-  - file
-  - http
-template_sources:
-  - http
-  - file
+data_sources: [ 'file' , 'http' ]
+template_sources: [ 'file' , 'http' ]
 ```
 
 Note that the ordering is significant. In the above example, values from the HTTP data source will take precedence over YAML files, but templates loaded from files will take precedence over templates stored in HTTP. You should tweak this as appropriate for your environment.
 
 You also do not need to enable both plugins; for example you may just want to retrieve values for your templates from a web server, but continue to use files to store your actual template content.
 
 # Configuring
-Configuration for this plugin is placed inside a "http" block. This can either be included in the top-level of `common.yaml` file, or in a per-environment block. See the main [README.md](https://github.com/markround/tiller/blob/master/README.md#common-configuration) for more information on this.
+Configuration for this plugin is placed inside a "http" block. This can either be included in the top-level of `common.yaml` file, or in a [per-environment block](file.md#overriding-common-settings).
 
 A sample configuration (showing the defaults for most parameters) is as follows :
 

docs/plugins/vault.md

@@ -23,7 +23,7 @@ The above example would use templates from files, and retrieve values from Vault
 
 
 # Configuring
-Configuration for this plugin is placed inside a "vault" block. This should be in the the top-level of `common.yaml` file, or in a per-environment block. See the main [README.md](https://github.com/markround/tiller/blob/master/README.md#common-configuration) for more information on this.
+Configuration for this plugin is placed inside a "vault" block. This should be in the the top-level of `common.yaml` file, or in a [per-environment block](file.md#overriding-common-settings).
 
 A sample configuration (showing the defaults for most parameters) is as follows :
 

docs/plugins/zookeeper.md

@@ -7,20 +7,16 @@ As of version 0.6.0, Tiller includes plugins to retrieve templates and values fr
 Add the `zookeeper` plugins in your `common.yaml`, e.g.
 
 ```yaml
-data_sources:
-  - file
-  - zookeeper
-template_sources:
-  - zookeeper
-  - file
+data_sources: [ 'file' , 'zookeeper' ]
+template_sources: [ 'file' , 'zookeeper' ]
 ```
 
 Note that the ordering is significant. In the above example, values from the ZooKeeper data source will take precedence over YAML files, but templates loaded from files will take precedence over templates stored in ZooKeeper. You should tweak this as appropriate for your environment.
 
 You also do not need to enable both plugins; for example you may just want to retrieve values for your templates from ZooKeeper, but continue to use files to store your actual template content.
 
 # Configuring
-Configuration for this plugin is placed inside a "zookeeper" block. This can either be included in the main `common.yaml` file, or in a per-environment configuration block inside a `common:` block. See the main [README.md](https://github.com/markround/tiller/blob/master/README.md#common-configuration) for more information on this.
+Configuration for this plugin is placed inside a "zookeeper" block. This can either be included in the main `common.yaml` file, or in a [per-environment block](file.md#overriding-common-settings).
 
 A sample configuration (showing the defaults for most parameters) is as follows :
 ```yaml