Merge pull request #169 from jaredledvina/feature/some-doc-cleanup

Doc cleanup, update links, nuke some old stuff

docs/afewwords.md

@@ -4,22 +4,16 @@ Well, thanks for bothering to even visit this page!
 This role was born out of my own passion for the absolutely excellent projects that it uses.
 I figure I have to list them, in no particular order, here they are. __Make sure to check them all out!__
 
-- [Ansible](http://ansible.com/home)
-- [Sensu](https://sensuapp.org/)
-- [Uchiwa](https://uchiwa.io/#/)
-- [SmartOS](https://smartos.org/)
-- [RabbitMQ](https://rabbitmq.com/)
-- [redis](http://redis.io/)
+- [Ansible](https://www.ansible.com/)
+- [Sensu](https://sensu.io/)
+- [Uchiwa](https://uchiwa.io/)
+- [SmartOS](https://www.joyent.com/smartos)
+- [RabbitMQ](https://www.rabbitmq.com/)
+- [redis](https://redis.io/)
 
 ## What about support for other operating systems?
-It's planned!
-
-Coming in the near future:
-
-- OpenBSD
-- NetBSD
-
-I'd be happy to add any others to the list if high demand shows.
+At this time, the role supports a plethora of operating systems. If there's 
+another one you'd like to see support for, please [file an issue!](https://github.com/sensu/sensu-ansible/issues)
 
 ## About updates
 This is a personal project of mine that I work on in my own free time.

docs/custom_client_config.md

@@ -1,7 +1,7 @@
 # Custom Client Configuration
-When this Ansible role deploys the Sensu client configuration - defined in `client.json` in the Sensu configuration directory, it works out [subscriptions](https://sensuapp.org/docs/latest/reference/clients#client-subscriptions) based on group membership within the Ansible inventory.
+When this Ansible role deploys the Sensu client configuration - defined in `client.json` in the Sensu configuration directory, it works out [subscriptions](https://docs.sensu.io/sensu-core/latest/reference/clients/#client-subscriptions) based on group membership within the Ansible inventory.
 For example, if you have a `webservers` group within your Ansible inventory, any nodes listed in that group will automatically gain a subscription to `webservers` within Sensu.
-This is quite a powerful, convenient feature. It's coupled with the deployment of [checks](https://sensuapp.org/docs/latest/guides/getting-started/intro-to-checks.html). If you add a new webserver to your infrastructure, Sensu will dynamically pick it up, subscribe it to 'webservers', and deploy webserver checks, without you having to do anything other than add that node into the `webservers` group within your Ansible inventory. Instantaneous monitoring of your web services!
+This is quite a powerful, convenient feature. It's coupled with the deployment of [checks](https://docs.sensu.io/sensu-core/latest/guides/intro-to-checks/). If you add a new webserver to your infrastructure, Sensu will dynamically pick it up, subscribe it to 'webservers', and deploy webserver checks, without you having to do anything other than add that node into the `webservers` group within your Ansible inventory. Instantaneous monitoring of your web services!
 
 The above is all very nice and fancy, but, what if you want to define some other properties for a specific node, or override its subscriptions altogether?
 
@@ -21,7 +21,7 @@ It's contents (as of writing) are as follows:
   }
 }
 ```
-As you can see from above, this configuration's values are all populated using [facts](http://docs.ansible.com/playbooks_variables.html#information-discovered-from-systems-facts).
+As you can see from above, this configuration's values are all populated using [facts](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#information-discovered-from-systems-facts).
 
 To override this for a single node, `sensu_client_config` can be set in the `host_vars/node_name.domain.name.yml` file. We can also override it for entire groups in `group_vars/group_name.yml`.
 

docs/deploy_plugins.md

@@ -1,7 +1,7 @@
 # Deployment of Handlers, Filters, and Mutators
 _Note:_ _If you haven't familiarized yourself with the concept of the static data store please read_['_Dynamic check deployment'_](dynamic_checks.md)
 
-Deployment of [handlers](https://sensuapp.org/docs/latest/reference/handlers), [filters](https://sensuapp.org/docs/latest/reference/filters), and [mutators](https://sensuapp.org/docs/latest/reference/mutators) is handled by leveraging templates and other data placed in the static data store.
+Deployment of [handlers](https://docs.sensu.io/sensu-core/latest/reference/handlers/), [filters](https://docs.sensu.io/sensu-core/latest/reference/filters/), and [mutators](https://docs.sensu.io/sensu-core/latest/reference/mutators/) is handled by leveraging templates and other data placed in the static data store.
 
 ## Static data store hierarchy with respect to handlers/filters/mutators
 To deploy your handlers, filters, and mutators, you'll need to have directories named after each under a directory called 'sensu' in your static data store:
@@ -28,7 +28,7 @@ data/static
 All three are deployed using Ansible's [template]() module. This allows the use of variables within your configurations, which can come in quite handy!
 
 Let's take a look at the stuff I've got for [Pushover](https://pushover.net/).
-First off, the [handler](https://sensuapp.org/docs/latest/guides/getting-started/intro-to-handlers) json file `pushover_handler.json.j2`:
+First off, the [handler](https://docs.sensu.io/sensu-core/1.4/guides/intro-to-handlers/) json file `pushover_handler.json.j2`:
 ``` json
 {
   "handlers": {
@@ -47,7 +47,6 @@ This is a simple handler definition, registering the `pushover` handler, and its
 ``` json
 {
         "pushover": {
-                "apiurl": "https://api.pushover.net/1/messages",
                 "userkey": "{{ sensu_pushover_userkey }}",
                 "token": "{{ sensu_pushover_token }}"
         }

docs/dynamic_checks.md

@@ -1,5 +1,5 @@
 # Check Deployment
-One of the awesome features of this role (if I do say so myself) is the deployment of Sensu [checks](https://sensuapp.org/docs/latest/reference/checks) on a dynamic basis. Deployment of which checks should be distributed to which nodes is determined from group membership within the Ansible inventory.
+One of the awesome features of this role (if I do say so myself) is the deployment of Sensu [checks](https://docs.sensu.io/sensu-core/latest/reference/checks/) on a dynamic basis. Deployment of which checks should be distributed to which nodes is determined from group membership within the Ansible inventory.
 
 Have a group of webservers you need to monitor webservices on? Well, I'm sure you've bunched them together in your inventory under the `[webservers]` group, right? Or perhaps you only want to monitor disk space on your production systems; if they're a member of `[production]` within the inventory, you can do this easily.
 
@@ -84,7 +84,7 @@ tater.cmacr.ae
 web.cmacr.ae
 test.cmacr.ae
 ```
-Under these subdirectories, you can see [checks](https://sensuapp.org/docs/latest/reference/checks) that relate to the directory they're placed in.
+Under these subdirectories, you can see [checks](https://docs.sensu.io/sensu-core/latest/reference/checks/) that relate to the directory they're placed in.
 For example, our `webservers` subdirectory includes a `check_nginx.sh` script, whilst the `rabbitmq_servers` subdirectory has one that most likely checks for RabbitMQ problems (it does... trust me).  
 
 So how do these checks actually get deployed to their associated nodes?
@@ -107,7 +107,7 @@ With this pair of plays, in the `tasks/plugins.yml` playbook:
       - group_names
     notify: restart sensu-client service
 ```
-This will [register](http://docs.ansible.com/playbooks_conditionals.html#register-variables) a list of available checks, then deploy them to their intended groups based on node membership, as set within the Ansible inventory.
+This will [register](https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#register-variables) a list of available checks, then deploy them to their intended groups based on node membership, as set within the Ansible inventory.
 
 And, because nodes can of course be members of more than just one group, checks will be deployed in full to nodes that belong to several groups!
 

docs/dynamic_data.md

@@ -16,7 +16,7 @@ Using this `.gitignore` ensures that the directory (and the `.gitignore`) are ke
 The idea behind having this "empty" directory within your codebase is that, when deploying your Ansible codebase to your Ansible control node, it ensures the directory is there. This directory is then used in conjunction with some roles to store node specific data that you may wish to distribute amongst other nodes.
 
 ## Use of the dynamic data store in this Sensu role
-If you take a look at the `tasks/ssl.yml` playbook, there's a use of the [`fetch`](http://docs.ansible.com/fetch_module.html) module.
+If you take a look at the `tasks/ssl.yml` playbook, there's a use of the [`fetch`](https://docs.ansible.com/ansible/latest/modules/fetch_module.html) module.
 
 >This module works like `copy`, but in reverse. It is used for fetching files from remote machines and storing them locally in a file tree, organized by hostname.
 
@@ -48,7 +48,7 @@ data/dynamic/
                                 |-- cert.pem
                                 `-- key.pem
 ```
-As you can see, it resembles the file tree from the node it fetched the data from. This is configurable behavior, and can be set otherwise if you find this inconvenient/unsightly. See [ the `fetch` documentation](http://docs.ansible.com/fetch_module.html) for more information.
+As you can see, it resembles the file tree from the node it fetched the data from. This is configurable behavior, and can be set otherwise if you find this inconvenient/unsightly. See [ the `fetch` documentation](https://docs.ansible.com/ansible/latest/modules/fetch_module.html) for more information.
 
 ## Deployment of the data fetched to the dynamic data store
 Next up is this little play (from the `tasks/ssl.yml` playbook):

docs/example_infra.md

@@ -57,11 +57,9 @@ You can see I decided I want the Uchiwa dashboard to be deployed also, so I set
 The above code could also be set straight in the node's `host_vars` file: `host_vars/sensu.cmacr.ae.yml` or set straight in a playbook intended just for the `sensu_masters` node:
 ``` yaml
   - hosts: sensu_masters
-
     vars:
 	  sensu_master: true
 	  sensu_include_dashboard: true
-
     roles:
 	  - sensu.sensu
 ```

docs/index.md

@@ -2,33 +2,39 @@
 An [Ansible](https://ansible.com) role that deploys a full [Sensu](https://sensuapp.org) stack, a modern, open source monitoring framework.
 
 ## Features
-- Deploy a full [Sensu](https://sensuapp.org) stack, including RabbitMQ, redis, and the [Uchiwa dashboard](https://uchiwa.io/#/)
+- Deploy a full [Sensu](https://sensu.io) stack, including RabbitMQ, redis, and the [Uchiwa dashboard](https://uchiwa.io/)
 - Tight integration with the Ansible inventory - deployment of monitoring checks based on inventory grouping
 - Fine grained control over dynamic client configurations
 - Remote plugin deployment
-- Automatic generation and dynamic deployment of SSL certs for secure communication between your clients and servers
+- Automatic generation and dynamic deployment of self-signed SSL certs for secure communication between your clients and servers
 - Highly configurable
 
 ## Batteries included, but not imposed
-Along with deploying the Sensu Server, API and clients, this role can deploy a full stack: [RabbitMQ](http://www.rabbitmq.com/), [redis](http://redis.io), and the [Uchiwa dashboard](https://uchiwa.io/#/).
+Along with deploying the Sensu Server, API and clients, this role can deploy a full stack: [RabbitMQ](https://www.rabbitmq.com/), [redis](https://redis.io), and the [Uchiwa dashboard](https://uchiwa.io/).
 However, if you want to rely on other roles/management methods to deploy/manage these services, [it's nice and easy to integrate this role](integration/).
 
 ## Requirements
-This role requires Ansible 2.0
+This role requires Ansible 2.3
 
 ## Supported Platforms
-### Current Release
+### Automatically tested via TravisCI
 
-- [SmartOS - base-64 15.x.x](https://docs.joyent.com/images/smartos/base#version-15xx)
+- [CentOS - 6](https://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.9)
 - [CentOS - 7](https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7)
 - [Debian - 8 (Jessie)](https://wiki.debian.org/DebianJessie)
+- [Debian - 9 (Stretch)](https://wiki.debian.org/DebianStretch)
+- [Ubuntu - 14.04 (Trusty Tahr)](http://releases.ubuntu.com/14.04/)
 - [Ubuntu - 16.04 (Xenial Xerus)](http://releases.ubuntu.com/16.04/)
-- [FreeBSD - 10.3, 11.0 (64-bit only)](https://www.freebsd.org/releases/10.2R/relnotes.html)
+- [Fedora - 26](https://docs.fedoraproject.org/f26/release-notes/)
+- [Fedora - 27](https://docs.fedoraproject.org/f27/release-notes/)
+- [Fedora - 28](https://docs.fedoraproject.org/f28/release-notes/)
+- [Amazon Linux](https://aws.amazon.com/amazon-linux-ami/)
+- [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/)
 
-### Future Releases
-
-- OpenBSD
-- NetBSD
+### Supported manually (compatibility not always guaranteed)
+- [SmartOS - base-64 15.x.x](https://docs.joyent.com/images/smartos/base#version-15xx)
+- [FreeBSD - 10.3, 11.0 (64-bit only)](https://www.freebsd.org/releases/10.2R/relnotes.html)
+- [OpenBSD - 6.2](https://www.openbsd.org/62.html)
 
 ## Role Variables
 All variables have sensible defaults, which can be found in `defaults/main.yml`.
@@ -50,7 +56,9 @@ Or, passing parameter values:
 ``` yaml
   - hosts: sensu_masters
     roles:
-	  - { role: sensu.sensu, sensu_master: true, sensu_include_dashboard: true  }
+      - role: sensu.sensu
+        sensu_master: true
+        sensu_include_dashboard: true 
 ```
 
 License
@@ -66,5 +74,7 @@ Supported by the [Sensu Community Ansible Maintainers](https://github.com/sensu-
 See the projects [Contributors page](https://github.com/sensu/sensu-ansible/graphs/contributors)
 
 Feel free to:
+
 [Raise an issue](https://github.com/sensu/sensu-ansible/issues)
+
 [Contribute](https://github.com/sensu/sensu-ansible/pulls)

docs/remote_plugins.md

@@ -6,7 +6,7 @@ sensu_remote_plugins:
   - graphite
   - process-checks
 ```
-This will install the `graphite` and `process-checks` plugins from [sensu-plugins.io](http://sensu-plugins.io/).  
+This will install the `graphite` and `process-checks` plugins from [https://github.com/sensu-plugins/](https://github.com/sensu-plugins/).  
 
 Specific versions of plugins can also be defined, as shown below:
 ``` yaml