Moving to python 3 and dropping support for python 2.x (on deployer host)

.travis.yml

@@ -1,18 +1,20 @@
 ---
+dist: xenial
 sudo: required
 language: python
-python: 2.7
+python:
+  - 3.5
 cache: pip
 services:
   - docker
 env:
-  - ANSIBLE=2.5
   - ANSIBLE=2.6
   - ANSIBLE=2.7
+  - ANSIBLE=2.8
 matrix:
   fast_finish: true
 install:
-  - pip install tox-travis git-semver
+  - pip3 install tox-travis git-semver
 script:
   - tox
 deploy:

CONTRIBUTING.md

@@ -1,6 +1,8 @@
 # Contributor Guideline
 
-This document provides an overview of how you can participate in improving this project or extending it. We are grateful for all your help: bug reports and fixes, code contributions, documentation or ideas. Feel free to join, we appreciate your support!!
+This document provides an overview of how you can participate in improving this project or extending it. We are
+grateful for all your help: bug reports and fixes, code contributions, documentation or ideas. Feel free to join, we 
+appreciate your support!!
 
 ## Communication
 
@@ -10,7 +12,8 @@ You can talk with us on #cloudalchemy channel on freenode.
 
 ### GitHub repositories
 
-Much of the issues, goals and ideas are tracked in the respective projects in GitHub. Please use this channel to report bugs.
+Much of the issues, goals and ideas are tracked in the respective projects in GitHub. Please use this channel to report
+bugs.
 
 ## git and GitHub
 
@@ -26,47 +29,61 @@ To have your code merged, see the expectations listed below.
 
 You can find a well-written guide [here](https://help.github.com/articles/fork-a-repo).
 
-Please follow common commit best-practices. Be explicit, have a short summary, a well-written description and references. This is especially important for the merge-request.
+Please follow common commit best-practices. Be explicit, have a short summary, a well-written description and
+references. This is especially important for the merge-request.
 
-Some great guidelines can be found [here](https://wiki.openstack.org/wiki/GitCommitMessages) and [here](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).
+Some great guidelines can be found [here](https://wiki.openstack.org/wiki/GitCommitMessages) and
+[here](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).
 
 ## Releases
 
-We try to stick to semantic versioning and our releases are made by CI pipeline. It is done by assigning a keyword (in a way similar to travis [`[ci skip]`](https://docs.travis-ci.com/user/customizing-the-build#Skipping-a-build)) to a commit with merge request. Available keywords are (square brackets are important!):
+We try to stick to semantic versioning and our releases are automated. Release is created by assigning a keyword (in a
+way similar to travis [`[ci skip]`](https://docs.travis-ci.com/user/customizing-the-build#Skipping-a-build)) to a 
+commit with merge request. Available keywords are (square brackets are important!):
 
 * `[patch]`, `[fix]` - for PATCH version release
 * `[minor]`, `[feature]`, `[feat]` - for MINOR version release
 * `[major]`, `[breaking change]` - for MAJOR version release
 
 ## Changelog
 
-Changelog is generateg automatically on every merged Pull Request and all information is taken from github issues, PRs and labels.
+Changelog is generateg automatically on every merged Pull Request and all information is taken from github issues, PRs
+and labels.
 
 ## Expectations
 
 ### Keep it simple
 
-We try to provide production ready ansible roles which should be as much zero-conf as possible but this doesn't mean to overcomplicate things. Just follow [KISS](https://en.wikipedia.org/wiki/KISS_principle).
+We try to provide production ready ansible roles which should be as much zero-conf as possible but this doesn't mean to
+overcomplicate things. Just follow [KISS](https://en.wikipedia.org/wiki/KISS_principle).
 
 ### Be explicit
 
 * Please avoid using nonsensical property and variable names.
 * Use self-describing attribute names for user configuration.
-* In case of failures, communicate what happened and why a failure occurs to the user. Make it easy to track the code or action that produced the error. Try to catch and handle errors if possible to provide improved failure messages.
+* In case of failures, communicate what happened and why a failure occurs to the user. Make it easy to track the code
+or action that produced the error. Try to catch and handle errors if possible to provide improved failure messages.
 
 
 ### Add tests
 
-Currently we are using two test scenarios located in [/molecule](molecule) directory. First ([default](molecule/default/molecule.yml)) one is testing default configuration without any additional variables, second one ([alternative](molecule/alternative/molecule.yml)) is testing what happens when many variables from [/defaults/main.yml](defaults/main.yml) are changed. When adding new functionalities please add tests to proper scenarios. Tests are written in testinfra framework and are located in `/tests` subdirectory of scenario directory (for example default tests are in [/molecule/default/tests](molecule/default/tests)).
+We are striving to use at least two test scenarios located in [/molecule](molecule) directory. First one
+([default](molecule/default)) is testing default configuration without any additional variables, second one 
+([alternative](molecule/alternative)) is testing what happens when many variables from 
+[/defaults/main.yml](defaults/main.yml) are changed. When adding new functionalities please add tests to proper
+scenarios. Tests are written in testinfra framework and are located in `/tests` subdirectory of scenario directory
+(for example default tests are in [/molecule/default/tests](molecule/default/tests)).
 More information about:
   - [testinfra](http://testinfra.readthedocs.io/en/latest/index.html)
   - [molecule](https://molecule.readthedocs.io/en/latest/index.html)
 
 ### Follow best practices
 
-Please follow [ansible best practices](http://docs.ansible.com/ansible/latest/playbooks_best_practices.html) and especially provide meaningful names to tasks and even comments where needed.
+Please follow [ansible best practices](http://docs.ansible.com/ansible/latest/playbooks_best_practices.html) and
+especially provide meaningful names to tasks and even comments where needed.
 
-Our test framework automatically lints code with [`yamllint`](https://yamllint.readthedocs.io) and [`ansible-lint`](https://github.com/willthames/ansible-lint) programs so be sure to follow their rules.
+Our test framework automatically lints code with [`yamllint`](https://yamllint.readthedocs.io) and
+[`ansible-lint`](https://github.com/willthames/ansible-lint) programs so be sure to follow their rules.
 
 Remember: Code is generally read much more often than written.
 

README.md

@@ -132,19 +132,15 @@ tox
 ```
 To run a custom molecule command on custom environment with only default test scenario:
 ```sh
-tox -e py27-ansible25 -- molecule test -s default
+tox -e py35-ansible28 -- molecule test -s default
 ```
 For more information about molecule go to their [docs](http://molecule.readthedocs.io/en/latest/).
 
 If you would like to run tests on remote docker host just specify `DOCKER_HOST` variable before running tox tests.
 
 ## Travis CI
 
-Combining molecule and travis CI allows us to test how new PRs will behave when used with multiple ansible versions and multiple operating systems. This also allows use to create test scenarios for different role configurations. As a result we have a quite large test matrix (42 parallel role executions in case of [ansible-prometheus](https://github.com/cloudalchemy/ansible-prometheus)) which will take more time than local testing, so please be patient.
-
-## Changelog
-
-See [changelog](CHANGELOG.md).
+Combining molecule and travis CI allows us to test how new PRs will behave when used with multiple ansible versions and multiple operating systems. This also allows use to create test scenarios for different role configurations. As a result we have a quite large test matrix which will take more time than local testing, so please be patient.
 
 ## Contributing
 

meta/main.yml

@@ -4,22 +4,22 @@ galaxy_info:
   description: Prometheus monitoring system configuration and management
   license: MIT
   company: none
-  min_ansible_version: 2.5
+  min_ansible_version: 2.6
   platforms:
-  - name: Ubuntu
-    versions:
-    - bionic
-    - xenial
-  - name: Debian
-    versions:
-    - jessie
-    - stretch
-  - name: EL
-    versions:
-    - 7
-  - name: Fedora
-    versions:
-    - 27
+    - name: Ubuntu
+      versions:
+        - bionic
+        - xenial
+    - name: Debian
+      versions:
+        - jessie
+        - stretch
+    - name: EL
+      versions:
+        - 7
+    - name: Fedora
+      versions:
+        - 30
   galaxy_tags:
   - monitoring
   - prometheus

tox.ini

@@ -1,20 +1,20 @@
 [tox]
 minversion = 1.8
-envlist = py{27}-ansible{25,26,27}
+envlist = py{35}-ansible{26,27,28}
 skipsdist = true
 
 [travis:env]
 ANSIBLE=
-  2.5: ansible25
   2.6: ansible26
   2.7: ansible27
+  2.8: ansible28
 
 [testenv]
 passenv = *
 deps =
     -rtest-requirements.txt
-    ansible25: ansible<2.6
     ansible26: ansible<2.7
     ansible27: ansible<2.8
+    ansible28: ansible<2.9
 commands =
     {posargs:molecule test --all --destroy always}