jaredledvina / sensu-go-ansible

Ansible role to deploy and manage Sensu Go

sensu-go-ansible

This role allows for the deployment and management of Sensu Go.

The official Sensu supported Ansible Collection can be found here: https://github.com/sensu/sensu-go-ansible

If you'd like to contribute, please review CONTRIBUTING.md and open an issue to discuss your idea.

Requirements

• Ansible 2.9

Role Variables

See defaults/main.yml for everything that's configurable. If any of the options are unclear, please file an issue!

Please note that unless you've configured hash_behaviour to merge configuring any of the hash variables will override the entire default variable.

Most variables expose an _overrides: {} variable that is merged automatically in this role for selectively updating each variable. It's strongly recommended that the _overrides variable be used.

Dependencies

None

Example Playbook

The following example will configure the host in the hostgroup sensu-backend-server to be configured with both sensu-backend and sensu-agent. This host will also get the sensuctl CLI tool for further management of Sensu Go.

The hosts in sensu-agent-severs will only get the sensu-agent install and will have the sensu-agent's configuration option for backend-url overriden to ws://sensu-backend-server:8081.

For more information on the availible configuration options, checkout the upstream docs for sensu-backend and sensu-agent.

---
-
  hosts: sensu-backend-server
  become: yes
  roles:
    - role: jaredledvina.sensu_go_ansible
-
  hosts: sensu-agent-severs
  roles:
    - role: jaredledvina.sensu_go_ansible
      sensu_go_components:
        - agent
      sensu_go_configs_override:
        agent:
          config:
            backend-url:
              - ws://sensu-backend-server:8081

Testing

This Ansible role is automatically tested via TravisCI on every commit. We specifically test using the version of Ansible and python declared in the Pipefile

The following Operating Systems are automatically tested:

• Amazon Linux
• Amazon Linux 2
• CentOS - 6
• CentOS - 7
• Debian - 8 (Jessie)
• Debian - 9 (Stretch)
• Debian - 10 (Buster)
• Fedora - 30
• Fedora - 31
• Ubuntu - 16.04 (Xenial Xerus)
• Ubuntu - 18.04 (Bionic Beaver)

Custom Modules

This role includes the following custom modules:

• sensu-go-check

At this time, these modules are in preview status and may be subject to breaking changes. However, effort will be put in to attempt to not break the them, if possible. Please ensure you review the CHANGELOG when upgrading.

As described in the upstream documentation, to use the included custom modules, you must first include this role prior to calling the modules. After this role has been included once, they will be availble to subsequent plays/roles.

Currently, documentation for each module is in the DOCUMENTATION block in each modules source. Once the modules stabalized, they may be PR'ed upstream to the Ansible project.

Caveats

If you are using this role with Amazon Linux or Amazon Linux 2, you must override the following variables on those host(s):

Amazon Linux:

sensu_go_repos_overrides:
  yum:
    rpm: https://packagecloud.io/sensu/stable/el/6/x86_64
    rpm-src: https://packagecloud.io/sensu/stable/el/6/SRPMS
sensu_go_community_repos_overrides:
  yum:
    rpm: https://packagecloud.io/sensu/community/el/6/x86_64
    rpm-src: https://packagecloud.io/sensu/community/el/6/SRPMS

Amazon Linux 2:

sensu_go_repos_overrides:
  yum:
    rpm: https://packagecloud.io/sensu/stable/el/7/x86_64
    rpm-src: https://packagecloud.io/sensu/stable/el/7/SRPMS
sensu_go_community_repos_overrides:
  yum:
    rpm: https://packagecloud.io/sensu/community/el/7/x86_64
    rpm-src: https://packagecloud.io/sensu/community/el/7/SRPMS

If you are using this role with Debian 8, 9, or 10 hosts, you must overide the following variable:

sensu_go_manage_community_repo: false

This is due to Debian packages not being updated to the community repos pending the resolution of sensu/sensu-plugins-omnibus#3

License
-------

[MIT](https://github.com/jaredledvina/sensu-go-ansible/blob/master/LICENSE)


## License
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fjaredledvina%2Fsensu-go-ansible.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fjaredledvina%2Fsensu-go-ansible?ref=badge_large)

sensu-go-ansible's Issues

Update KitchenCI tests to work in TravisCI

I opted to use kitchen-vagrant as getting everything to work in Docker was getting really painful. However, I'm going to need work through that and migrate them to either kitchen-dokken or kitchen-docker.

It looks like kitchen-dokken requires Chef reading through it's README here: https://github.com/someara/kitchen-dokken#what-about-kitchen-docker

Dependabot couldn't authenticate with https://pypi.python.org/simple/

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Reach out to flowerysong

@flowerysong made a great set of modules in https://github.com/flowerysong/ansible-sensu-go/

Perhaps we could work together! 🎉

I'm more than happy to nuke sensu_go_check from here, was just an attempt to get something for the community.

more documentation around deploying clustered mode

Firstly, this is a great role. It's worked as expected. It would be good if the docs included an example of a playbook for a clustered deployment. I'm guessing I need to use the variable sensu_go_configs_override: {}, but I have no idea if that's accurate. I'm going to test now... stay tuned.

Release 0.1.0

Welcome to the first release of the Sensu Go Ansible role! 🎉

This role has been in use for a while now and is proving stable. Please checkout the README for some example usage and current caveats.

If you would like to add or see a new feature get added, please checkout CONTRIBUTING for details!

Dependabot can't resolve your Python dependency files

Dependabot can't resolve your Python dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

ERROR: ERROR: Could not find a version that matches markupsafe<2.0.0,>=2.0.0rc2
Tried: 0.9, 0.9.1, 0.9.2, 0.9.3, 0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, 1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0
Skipped pre-versions: 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2
There are incompatible versions in the resolved dependencies.
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/.pyenv/versions/3.7.10/lib/python3.7/site-packages/pipenv/utils.py", line 726, in resolve_deps
[pipenv.exceptions.ResolutionFailure]:       req_dir=req_dir,
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/.pyenv/versions/3.7.10/lib/python3.7/site-packages/pipenv/utils.py", line 480, in actually_resolve_deps
[pipenv.exceptions.ResolutionFailure]:       resolved_tree = resolver.resolve()
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/.pyenv/versions/3.7.10/lib/python3.7/site-packages/pipenv/utils.py", line 395, in resolve
[pipenv.exceptions.ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches markupsafe<2.0.0,>=2.0.0rc2
[pipenv.exceptions.ResolutionFailure]:       Tried: 0.9, 0.9.1, 0.9.2, 0.9.3, 0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, 1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0
[pipenv.exceptions.ResolutionFailure]:       Skipped pre-versions: 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
 Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ERROR: Could not find a version that matches markupsafe<2.0.0,>=2.0.0rc2
Tried: 0.9, 0.9.1, 0.9.2, 0.9.3, 0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, 1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.0, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 1.1.1, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0, 2.0.0
Skipped pre-versions: 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0a1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc1, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2, 2.0.0rc2
There are incompatible versions in the resolved dependencies.

['Traceback (most recent call last):\n', '  File "/usr/local/.pyenv/versions/3.7.10/lib/python3.7/site-packages/pipenv/utils.py", line 501, in create_spinner\n    yield sp\n', '  File "/usr/local/.pyenv/versions/3.7.10/lib/python3.7/site-packages/pipenv/utils.py", line 649, in venv_resolve_deps\n    c = resolve(cmd, sp)\n', '  File "/usr/local/.pyenv/versions/3.7.10/lib/python3.7/site-packages/pipenv/utils.py", line 539, in resolve\n    sys.exit(c.return_code)\n', 'SystemExit: 1\n']

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Dependabot couldn't authenticate with https://pypi.python.org/simple/

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Can't Add Command Line Arguments Once Check is Configured

First up, just to say, the sensu_go_plugin library looks great - it's helped me get some monitoring on some stuff that's really in need of it ;-)

Onto my observation: Once a check has been configured, it can't be changed without removing it and re-inserting it. As a test case, doing this with ad-hoc:

ansible myserver -m sensu_go_check -a 'name="fred" command="check_cpu.rb" subscriptions="test" state=present'

This returns the check configuration, which looks correct:

myserver | SUCCESS => {
    "changed": true, 
    "checks": [
        {
           "check_hooks": null, 
            "command": "check_cpu.rb", 
            "env_vars": null, 
            "handlers": [], 
            "high_flap_threshold": 0, 
            "interval": 60, 
            "low_flap_threshold": 0, 
            "metadata": {
                "name": "fred", 
                "namespace": "default"
            }, 
            "output_metric_format": "", 
            "output_metric_handlers": [], 
            "proxy_entity_name": "", 
            "publish": true, 
            "round_robin": false, 
            "runtime_assets": [], 
            "stdin": false, 
            "subdue": null, 
            "subscriptions": [
                "test"
            ], 
            "timeout": 0, 
            "ttl": 0
        }
    ], 
    "message": "OK"
}

All fine so far. However, an attempt to update it with:

ansible myserver -m sensu_go_check -a 'name="fred" command="check_cpu.rb -w 80 -c 90" subscriptions="test" state=present'

Returns:

myserver | SUCCESS => {
    "changed": false, 
    "message": "Check already defined in Sensu"
}

If the above check is removed with a state=absent and then re-added using the same command as above then it is correctly updated in both the console output and in the Sensu web UI.

I had a bit of a look at the library code - I'm not entirely sure how to approach any possible solution. Since a 'list' operation returns everything the server knows, I guess it could just be a matter of stepping through the list output looking for the current 'name'. If found, either update it (if the API allows) or remove and re-add if not...? It could make the whole thing pretty slow, although each 'add' would update the list. Another option would be to try to add it anyway, and then get the list if you get the 'Check already defined in Sensu' message. Lastly, maybe it's an upstream change to the Sensu API to do the update if we're asking for a slightly different check?

default user and password

Hi, thanks for your great work.

I am wondering what would be the default user and password for logging into sensu dashboard using your ansible role.

I cannot find it in your code. I also tried the defaulr admin user with P@ssw0rd! as a password but It doesn't work

Thanks in advance.

sensu-go-check module fails with python3

python config:

ansible_python_interpreter=/usr/bin/python3

error:

TASK [Create a new check] *****************************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: the JSON object must be str, not 'bytes'
fatal: [sensu-go]: FAILED! => {"changed": false, "msg": "Failed to parse response as JSON: {'msg': 'OK (601 bytes)', 'date': 'Sun, 28 Jul 2019 19:38:27 GMT', 'cookies': {}, 'content-length' ....

If I change python back to version 2, everything works as expected

Molecule tests are failing on docker driver

Thanks for this role. Just checked out the code and wanted to run CentOS tests on Docker:

pipenv run molecule --base-config molecule/shared/base.yml test --scenario-name centos

But it fails because dokken/centos-7 container does not have systemd configured:

TASK [sensu-go-ansible : Ensure sensu-backend service state] *******************
    Wednesday 31 July 2019  13:18:39 +0200 (0:00:00.147)       0:01:21.624 ********
    fatal: [centos-7]: FAILED! => changed=false 
      cmd: /usr/bin/systemctl
      msg: 'Failed to get D-Bus connection: Operation not permitted'
      rc: 1
      stderr: |-
        Failed to get D-Bus connection: Operation not permitted
      stderr_lines: <omitted>
      stdout: ''
      stdout_lines: <omitted>

Are there perhaps some pre-configure steps missing to tweak the centos image prior running the role on it?

sensu-go-check module examples have invalid options

• user should be username
• command is required (for state=present)

Add CentOS support

Currently, this only tests Debian 9 and supports apt based systems.
Let's update the role to start with supporting CentOS 7 and yum based systems.

check name moved under metadata dictionary

Hello!

When trying to use sensu_go_check with ansible 2.7.4, and sensu-go 5.0.0 I get a module failure. Further debugging shows me:

root@vps216011:/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/debug_dir# /tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/AnsiballZ_sensu_go_check.py execute
Traceback (most recent call last):
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/AnsiballZ_sensu_go_check.py", line 261, in <module>
    _ansiballz_main()
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/AnsiballZ_sensu_go_check.py", line 248, in _ansiballz_main
    exitcode = debug(sys.argv[1], zipped_mod, ANSIBALLZ_PARAMS)
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/AnsiballZ_sensu_go_check.py", line 216, in debug
    importer = imp.load_module('__main__', f, script_path, ('.py', 'r', imp.PY_SOURCE))
  File "/usr/lib/python3.6/imp.py", line 235, in load_module
    return load_source(name, filename, file)
  File "/usr/lib/python3.6/imp.py", line 170, in load_source
    module = _exec(spec, sys.modules[name])
  File "<frozen importlib._bootstrap>", line 618, in _exec
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/debug_dir/__main__.py", line 191, in <module>
    main()
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/debug_dir/__main__.py", line 188, in main
    run_module()
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/debug_dir/__main__.py", line 141, in run_module
    check_names = [check['name'] for check in checks]
  File "/tmp/.ansible-root/tmp/ansible-tmp-1544296249.73-277063188930744/debug_dir/__main__.py", line 141, in <listcomp>
    check_names = [check['name'] for check in checks]
KeyError: 'name'

Outputting 'check list' with json shows that 'name' key has moved under metadata dictionary:

[
  {
    "command": "/opt/sensu-plugins-ruby/embedded/bin/check-wsrep-ready.rb --user sensu",
    "handlers": [],
    "high_flap_threshold": 0,
    "interval": 60,
    "low_flap_threshold": 0,
    "publish": true,
    "runtime_assets": [],
    "subscriptions": [
      "percona-xtradb-cluster"
    ],
    "proxy_entity_name": "",
    "check_hooks": null,
    "stdin": false,
    "subdue": null,
    "ttl": 0,
    "timeout": 0,
    "round_robin": false,
    "output_metric_format": "",
    "output_metric_handlers": [],
    "env_vars": null,
    "metadata": {
      "name": "check-wsrep-ready",
      "namespace": "default"
    }
  }
]

I changed:

check_names = [check['name'] for check in checks]

To:

check_names = [check['metadata']['name'] for check in checks]

But I'm not sure that's the proper approach, but it's working for me now!

KeyError: 'labels' when using sensu_go_check

Hi, got a strange one... I don't know enough about Python to understand why this might be happening...

When running the playbook against my own CentOS 7 VM, it works just fine (running Python 2.7.5). However, when I run on our RHEL 7 servers, I get the following error:

Traceback (most recent call last):
  File "/tmp/ansible_E5dwNU/ansible_module_sensu_go_check.py", line 428, in <module>
    main()
  File "/tmp/ansible_E5dwNU/ansible_module_sensu_go_check.py", line 424, in main
    run_module()
  File "/tmp/ansible_E5dwNU/ansible_module_sensu_go_check.py", line 361, in run_module
    check_def = module.create_check_definition()
  File "/tmp/ansible_E5dwNU/ansible_modlib.zip/ansible/module_utils/sensu_go.py", line 187, in create_check_definition
KeyError: 'labels'

I noticed that the way it's checking for labels in metadata if different to the way it's done in the main check script..

I changed:
if self.params['metadata']['labels']:
in sensu_go.py to:
if 'labels' in self.params['metadata'] and self.params['metadata']['labels'] is not None:

and it started working straight away.

Again, I don't understand why it wouldn't work on a RHEL server when it's fine on CentOS with the same version of Python...

Also, I noticed I was getting idempotency failure when creating checks... I had to set a default for interval, since when using cron expressions, the module thinks there's a change..

interval=dict(type='int', default=0)

Dependabot couldn't authenticate with https://pypi.python.org/simple/

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

sensu-go-check failed to run

I try to use sensu-go-check module

1. Added module path to library path:
   cat /etc/ansible/ansible.cfg library = /usr/lib/python2.7/site-packages/ansible/modules:/etc/ansible/playbooks/sensu-go-ansible/library

2. Create yml file with check definition

---
- hosts: all
  tasks:
    - name: Create a new check
      sensu_go_check:
        state: present
        host: <hostname>
        protocol: https
        port: 8081
        password: <password>
        namespace: default
        subscriptions:
          - default
        name: check_root_disk
        command: /usr/lib64/nagios/plugins/check_disk -w 15 -c 10 -p "/"
        interval: 60
        validate_certs: no

3. run ansible
   ansible-playbook -i hosts checks.yml

4. get error

TASK [Create a new check] ***********************************************************************************************************************************
fatal: [172.22.155.230]: FAILED! => {"changed": false, "module_stderr": "Shared connection to 172.22.155.230 closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n  File \"/home/maximni/.ansible/tmp/ansible-tmp-1558048408.29-233429134634977/AnsiballZ_sensu_go_check.py\", line 113, in <module>\r\n    _ansiballz_main()\r\n  File \"/home/maximni/.ansible/tmp/ansible-tmp-1558048408.29-233429134634977/AnsiballZ_sensu_go_check.py\", line 105, in _ansiballz_main\r\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\r\n  File \"/home/maximni/.ansible/tmp/ansible-tmp-1558048408.29-233429134634977/AnsiballZ_sensu_go_check.py\", line 48, in invoke_module\r\n    imp.load_module('__main__', mod, module, MOD_DESC)\r\n  File \"/tmp/ansible_sensu_go_check_payload_jzafha/__main__.py\", line 489, in <module>\r\n  File \"/tmp/ansible_sensu_go_check_payload_jzafha/__main__.py\", line 485, in main\r\n  File \"/tmp/ansible_sensu_go_check_payload_jzafha/__main__.py\", line 444, in run_module\r\n  File \"/tmp/ansible_sensu_go_check_payload_jzafha/__main__.py\", line 322, in auth\r\nTypeError: 'NoneType' object has no attribute '__getitem__'\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}

Deprecated

👋

Please note that this Ansible role is now deprecated and will not be maintained going forward.

https://github.com/sensu/sensu-go-ansible is the official Ansible role for Sensu Go.