Merge pull request #206 from michaelpporter/feature/issue16

fix(issues) Attempt to address #16
Prefix all variables with sensu_

CHANGELOG.md

@@ -94,7 +94,7 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/).
 - `defaults/main.yaml`,`tasks/plugins.yml`: Fix Python 3.X compatability issue when checking the contents of sensu_remote_plugins. (@danragnar)
 
 ### Added
-- `templates/sensu-api-json.j2`, `templates/uchiwa_config.json.j2`: Check for explicitly defining uchiwa_users and sensu_api_user_name as empty to disable authentication, useful when having a reverse proxy handling auth in front of the API and/or the uchiwa dashboard (@danragnar)
+- `templates/sensu-api-json.j2`, `templates/uchiwa_config.json.j2`: Check for explicitly defining sensu_uchiwa_users and sensu_api_user_name as empty to disable authentication, useful when having a reverse proxy handling auth in front of the API and/or the uchiwa dashboard (@danragnar)
 - `tasks/rabbit.yml`: Consistency of remote_src option for rabbitmq and sensu when copying SSL cert/key files. Useful if certificates are generated by another CA (e.g. FreeIPA) on the sensu host. (@danragnar)
 
 ## [2.0.0] - 2018-02-07

defaults/main.yml

@@ -30,29 +30,29 @@ sensu_deploy_rabbitmq_server: true
 sensu_deploy_redis_server: true
 
 # RabbitMQ server properties
-rabbitmq_config_path: /etc/rabbitmq
-rabbitmq_config_template: rabbitmq.config.j2
-rabbitmq_enable_ssl: true
-rabbitmq_host: "{{ groups['rabbitmq_servers'][0] }}"
-rabbitmq_port: 5671
-rabbitmq_pkg_state: present
-rabbitmq_server: false
-rabbitmq_service_name: rabbitmq-server
-rabbitmq_sensu_user_name: sensu
-rabbitmq_sensu_password: sensu
-rabbitmq_sensu_vhost: /sensu
+sensu_rabbitmq_config_path: /etc/rabbitmq
+sensu_rabbitmq_config_template: rabbitmq.config.j2
+sensu_rabbitmq_enable_ssl: true
+sensu_rabbitmq_host: "{{ groups['rabbitmq_servers'][0] }}"
+sensu_rabbitmq_port: 5671
+sensu_rabbitmq_pkg_state: present
+sensu_rabbitmq_server: false
+sensu_rabbitmq_service_name: rabbitmq-server
+sensu_rabbitmq_user_name: sensu
+sensu_rabbitmq_password: sensu
+sensu_rabbitmq_vhost: /sensu
 
 # redis server properties
-redis_host: "{{ groups['redis_servers'][0] }}"
-redis_server: false
-redis_service_name: redis
-redis_pkg_repo: ~
-redis_pkg_name: redis
-redis_pkg_state: present
-redis_port: 6379
-redis_password:
-redis_sentinels: []
-redis_master_name:
+sensu_redis_host: "{{ groups['sensu_redis_servers'][0] }}"
+sensu_redis_server: false
+sensu_redis_service_name: redis
+sensu_redis_pkg_repo: ~
+sensu_redis_pkg_name: redis
+sensu_redis_pkg_state: present
+sensu_redis_port: 6379
+sensu_redis_password:
+sensu_redis_sentinels: []
+sensu_redis_master_name:
 sensu_redis_config: sensu-redis.json.j2
 
 # Sensu/Uchiwa user/group/service properties
@@ -101,23 +101,23 @@ sensu_ssl_server_cacert: "{{ sensu_ssl_tool_base_path }}/sensu_ca/cacert.pem"
 sensu_ssl_server_cert: "{{ sensu_ssl_tool_base_path }}/server/cert.pem"
 sensu_ssl_server_key: "{{ sensu_ssl_tool_base_path }}/server/key.pem"
 dynamic_data_store: "{{ playbook_dir }}/data/store"
-static_data_store: "{{ playbook_dir}}/data/static"
+static_data_store: "{{ playbook_dir }}/data/static"
 
 # Uchiwa properties
-uchiwa_dc_name: ~
-uchiwa_path: /opt/uchiwa
-uchiwa_redis_use_ssl: false
-uchiwa_users:
+sensu_uchiwa_dc_name: ~
+sensu_uchiwa_path: /opt/uchiwa
+sensu_uchiwa_redis_use_ssl: false
+sensu_uchiwa_users:
   - username: admin
     password: admin
-uchiwa_port: 3000
-uchiwa_refresh: 5
-uchiwa_sensu_api_port: "{{ sensu_api_port }}"
-uchiwa_auth_privatekey: ~
-uchiwa_auth_publickey: ~
+sensu_uchiwa_port: 3000
+sensu_uchiwa_refresh: 5
+sensu_uchiwa_api_port: "{{ sensu_api_port }}"
+sensu_uchiwa_auth_privatekey: ~
+sensu_uchiwa_auth_publickey: ~
 
 # CentOS repository for redis and rabbitmq
-centos_repository: epel
+sensu_centos_repository: epel
 
 # Internal settings
 __bash_path: /bin/bash

docs/dynamic_checks.md

@@ -21,9 +21,9 @@ $ tree data/static
 data/static
 `-- sensu
     |-- checks
-    |   |-- rabbitmq_servers
+    |   |-- sensu_rabbitmq_servers
     |   |   `-- check_rabbitmq.sh
-    |   |-- redis_servers
+    |   |-- sensu_redis_servers
     |   |   `-- check_redis.sh
     |   |-- webservers
     |   |   `-- check_nginx.sh
@@ -41,21 +41,21 @@ data/static
     |   |-- smartos_check_disk.json.j2
     |   `-- smartos_check_mem.json.j2
     |-- client_definitions
-    |   |-- rabbitmq_servers
+    |   |-- sensu_rabbitmq_servers
     |   |   `-- check_users.json.j2
     |   `-- webservers
     |       `-- check_uptime.json.j2
     |-- handlers
     |   `-- pushover.rb
     `-- mutators
 ```
-As you can see, in the `sensu/checks` directory, there are the `rabbitmq_servers`, `redis_servers`, `webservers` & `zones` subdirectories.
+As you can see, in the `sensu/checks` directory, there are the `sensu_rabbitmq_servers`, `sensu_redis_servers`, `webservers` & `zones` subdirectories.
 If you've had a peruse through some of the other documentation here, you'll know that these groups are defined within my Ansible inventory:
 ``` ini
-[rabbitmq_servers]
+[sensu_rabbitmq_servers]
 test.cmacr.ae
 
-[redis_servers]
+[sensu_redis_servers]
 redis.cmacr.ae
 
 [sensu_masters]
@@ -85,7 +85,7 @@ web.cmacr.ae
 test.cmacr.ae
 ```
 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).
+For example, our `webservers` subdirectory includes a `check_nginx.sh` script, whilst the `sensu_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?
 With this pair of plays, in the `tasks/plugins.yml` playbook:
@@ -147,10 +147,10 @@ In your Ansible inventory, after this spontaneous decision to have your webserve
 [webservers]
 mime.domain.name
 
-[redis_servers]
+[sensu_redis_servers]
 mime.domain.name
 ```
-Not to worry, the next time your playbook applying this Sensu role runs through (notably the `tasks/client.yml` & `tasks/plugins.yml` playbooks), the new checks for redis will be deployed to `mime.domain.name` and it'll be subscribed to the `redis_servers` stream within Sensu. Pretty slick, right?
+Not to worry, the next time your playbook applying this Sensu role runs through (notably the `tasks/client.yml` & `tasks/plugins.yml` playbooks), the new checks for redis will be deployed to `mime.domain.name` and it'll be subscribed to the `sensu_redis_servers` stream within Sensu. Pretty slick, right?
 
 The same goes for the removal of a node from a group. Did you just realize you really don't want `mime.domain.name` to act as a redis server?
-It's cool, we all make mistakes, just take him out of the `[redis_servers]` group in your inventory. When your play comes through again, applying this Sensu role, he'll be unsubscribed from the `redis_servers` stream, and redis'll stop being monitored!
+It's cool, we all make mistakes, just take him out of the `[sensu_redis_servers]` group in your inventory. When your play comes through again, applying this Sensu role, he'll be unsubscribed from the `sensu_redis_servers` stream, and redis'll stop being monitored!

docs/dynamic_data.md

@@ -72,7 +72,7 @@ The same method is used for node communication with RabbitMQ:
   - name: Ensure RabbitMQ SSL certs/keys are in place
     copy:
 	  src: "{{ item }}"
-	  dest: "{{ rabbitmq_config_path }}/ssl"
+	  dest: "{{ sensu_rabbitmq_config_path }}/ssl"
     loop:
       - "{{ sensu_ssl_server_cacert }}"
       - "{{ sensu_ssl_server_cert }}"

docs/example_infra.md

@@ -9,10 +9,10 @@ It ties in with use of inventory grouping and variables.
 Let's start with an example Ansible Inventory:
 
 ``` ini
-[rabbitmq_servers]
+[sensu_rabbitmq_servers]
 test.cmacr.ae
 
-[redis_servers]
+[sensu_redis_servers]
 redis.cmacr.ae
 
 [sensu_masters]
@@ -42,7 +42,7 @@ web.cmacr.ae
 test.cmacr.ae
 ```
 
-Here we have some nodes grouped into `rabbitmq_servers`, `redis_servers`, `sensu_masters`, `webservers`, and `zones`.
+Here we have some nodes grouped into `sensu_rabbitmq_servers`, `sensu_redis_servers`, `sensu_masters`, `webservers`, and `zones`.
 
 Since we only want one Sensu "master", the default to act as a master in this role is set to `false` - defined by `sensu_master`.
 
@@ -65,20 +65,20 @@ The above code could also be set straight in the node's `host_vars` file: `host_
 ```
 
 ### RabbitMQ/redis variables
-You'll probably have noticed the two groups `rabbitmq_servers` and `redis_servers` in the example inventory.
-Quite self explanatory what these are, but - as with the `sensu_master` variable in the previous section - both the `rabbitmq_server` & `redis_server` values are set to `false` by default (defined in `defaults/main.yml`).
+You'll probably have noticed the two groups `sensu_rabbitmq_servers` and `sensu_redis_servers` in the example inventory.
+Quite self explanatory what these are, but - as with the `sensu_master` variable in the previous section - both the `sensu_rabbitmq_server` & `sensu_redis_server` values are set to `false` by default (defined in `defaults/main.yml`).
 
 The same approach of setting these to `true` is taken here again.
 Once more, I opt to set these in `group_vars`, like so:
 
-`group_vars/rabbitmq_servers.yml`
+`group_vars/sensu_rabbitmq_servers.yml`
 ``` yaml
-rabbitmq_server: true
+sensu_rabbitmq_server: true
 ```
 
-`group_vars/redis_servers.yml`
+`group_vars/sensu_redis_servers.yml`
 ``` yaml
-redis_server: true
+sensu_redis_server: true
 ```
 
 The same can, again, be set directly in your RabbitMQ/redis nodes' `host_vars` files, or done so in the playbook as shown in the previous section for the values `sensu_master` & `sensu_include_dashboard`.

docs/integration.md

@@ -1,18 +1,18 @@
 Integration with other roles/management methods
 ===============================================
-Although this role can deploy and manage the full Sensu stack, you can opt to use other roles to manage RabbitMQ, redis, and the Uchiwa dashboard, if you so desire.  
+Although this role can deploy and manage the full Sensu stack, you can opt to use other roles to manage RabbitMQ, redis, and the Uchiwa dashboard, if you so desire.
 
 RabbitMQ
 --------
 If you'd like to use a different role/management method for RabbitMQ, the following variables are of interest:
 ``` yaml
 sensu_deploy_rabbitmq_server: false
-rabbitmq_host: < IP/DNS record of your RabbitMQ server >
-rabbitmq_port: < optionally set a differing port, defaults to 5671 >
-rabbitmq_sensu_user_name: < the username for interacting with RabbitMQ >
-rabbitmq_sensu_password: < the password for interacting with RabbitMQ >
-rabbitmq_sensu_vhost: < the RabbitMQ vhost to use, defaults to '/sensu' >
-rabbitmq_config_path: < the path to the RabbitMQ configuration >
+sensu_rabbitmq_host: < IP/DNS record of your RabbitMQ server >
+sensu_rabbitmq_port: < optionally set a differing port, defaults to 5671 >
+sensu_rabbitmq_user_name: < the username for interacting with RabbitMQ >
+sensu_rabbitmq_password: < the password for interacting with RabbitMQ >
+sensu_rabbitmq_vhost: < the RabbitMQ vhost to use, defaults to '/sensu' >
+sensu_rabbitmq_config_path: < the path to the RabbitMQ configuration >
 
 ```
 
@@ -23,8 +23,8 @@ redis
 If you'd like to use a different role/management method for redis, the following variables are of interest:
 ``` yaml
 sensu_deploy_redis_server: false
-redis_host: < IP/DNS record of your redis server >
-redis_port: < optionally set a differing port, defaults to 6379 >
+sensu_redis_host: < IP/DNS record of your redis server >
+sensu_redis_port: < optionally set a differing port, defaults to 6379 >
 ```
 
 Uchiwa dashboard