Coder Social home page Coder Social logo

sensu / sensu-go-ansible Goto Github PK

View Code? Open in Web Editor NEW
36.0 22.0 28.0 10.02 MB

Official Ansible module for Sensu Go

License: GNU General Public License v3.0

Python 98.51% Makefile 0.52% Shell 0.18% Jinja 0.78%
sensu ansible ansible-galaxy ansible-collection monitoring

sensu-go-ansible's Introduction

Development: Development status | Stable: Stable status

Sensu Go Ansible Collection

Sensu Go Ansible Collection is a bundle of Ansible content that we can use to manage all aspects of Sensu Go. It contains Ansible roles for installing and configuring backends and agents. Collection also contains a wide selection of modules for runtime management of Sensu Go backend.

Collection is freely available on Ansible Galaxy. For Red Hat subscribers, this collection is also available on Automation Hub.

For user guides and references, please visit the documentation site. And if you would like to help us out, check our hacking docs.

sensu-go-ansible's People

Contributors

aduston-wo avatar aljazkosir avatar amdprophet avatar dnikoloski avatar domendobnikar avatar flowerysong avatar ivantomica avatar jakeo avatar juremedvesek avatar mancabizjak avatar matejart avatar miha-plesko avatar mkobel avatar rgeniesse avatar tadeboro avatar tgdfool2 avatar uscinski avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sensu-go-ansible's Issues

objc[3764]: +[__NSCFConstantString initialize] when installing bonsai asset

Bug description
Calling the 'bonsai_asset' module errors out with when running Ansible from macOS 10.15.2:

How to reproduce the bug

  1. Create Ansible playbook.yml:
---
- hosts: sensuservers
  collections: [ sensu.sensu_go ]
  environment:
    SENSU_URL: http://sensuserver:8080
    SENSU_USER: admin
    SENSU_PASSWORD: password

  tasks:
    - name: Create prod namespace
      namespace:
        name: prod
        state: present

    - name: Ruby runtime asset
      bonsai_asset:
        name: sensu/sensu-ruby-runtime
        version: 0.0.10
  1. Execute ansible-playbook --vault-password-file ~/.vault -i hosts/sensuservers playbook.yml

Expected result
Install Bonsai asset

Actual result

PLAY [sensuservers] ***********************************************************************************

TASK [Gathering Facts] *********************************************************************************
ok: [sensuserver]

TASK [Create prod namespace] ***************************************************************************
changed: [sensuserver]

TASK [Ruby runtime asset] ******************************************************************************
objc[4083]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[4083]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
ERROR! A worker was found in a dead state

Component versions

  • macOS 10.15.2 (Catalina)
  • Ansible Version 2.9.2 (python v3.7.6)
  • Sensu Go Backend Version 5.16.1

Centralized authentication

Currently each Sensu module performs API authenticatication, which becomes quite redundant in scenario where we invoke multiple Sensu modules in the same play. What we could do is implement connection plugin that would do the following:

  1. grab token from play vars if present and pass it to module
  2. in case token was not present in play vars, let module authenticate against Sensu backend. Connection plugin then grabs that token ans stores it as a play variable

This way Sensu modules would be able to reuse token from other Sensu module invocations so they would not need to authenticate everytime.

Bonsai Plugin Broken in 1.1.0

Bug description
attempting to use the bonsai asset plugin as per the example:

- name: Make sure specific version of asset is installed
 bonsai_asset:
   name: sensu/monitoring-plugins
   version: 2.2.0-1

yields:

  "changed": false,
    "msg": "name should be <type 'str'>",
    "warning": [
        "ActionModule.run() no longer honors the tmp parameter. Action plugins should set self._connection._shell.tmpdir to share the tmpdir"
    ]

Component versions

  • Ansible Version [e.g. 2.9.0]
  • Sensu Go Collection Version [e.g. 1.1.0]
  • Sensu Go Backend Version [e.g. 5.16.0]

README needs some additional clarity regarding Ansible 2.8 & Mazer

Currently if I am looking to use this collection, I'm directed to use Mazer. Upon heading to Ansible's documentation using Mazer, I'm informed that it is deprecated and to use Ansible 2.9. While it's possible to upgrade Ansible using pip, the reality is that for any user who's using Redhat and/or Ansible tower, Ansible 2.9 isn't readily available, so using Mazer is the only option...but this results in a bit of a circular dependency.

The last documentation available on installing mazer I could find is here: https://github.com/ansible/galaxy/blob/e6030874286a79fd94e83b92f37ad450682e9742/docs/docsite/rst/mazer/install.rst. Would it be possible to add this to the README so that we're not chasing our tails?

Add support for secrets in check, handler and mutator definitions

Sensu Go 5.17.0 introduced a new secret resource that can be used when defining a check, handler, or mutator. Sensu Go Ansible modules currently do not support this attribute.

In order to support this, we need to add another parameter to the affected modules. So the plan of attack is:

  1. Add new documentation fragment for secrets parameter.
  2. Add argument specification for secrets parameter,
  3. Update modules to include the documentation fragment and add an additional parameter to arg spec construction.
  4. Add an additional parameter to the payload construction call.

Unable to use the namespace metadata attribute.

In using assets, I would like to have them created in multiple namespaces. As resources like assets can only live in one namespace, this requires specifying the namespace in the resource definition.

Looking here:

https://github.com/sensu/sensu-go-ansible/blob/master/plugins/modules/asset.py#L102

It would seem as though they are not supported. I searched the repo for mentions of namespace and didn't see anywhere else that it would come into play, however I only know Python enough to get me into trouble.

This is further supported by an error when namespace is used in an asset module:

"msg": "Unsupported parameters for (sensu.sensu_go.asset) module: namespace Supported parameters include: annotations, auth, filters, headers, labels, name, sha512, state, url"}

As namespaces are a supported module in this collection, users wouldn't actually be able to use anything else except for default. I also found that other modules, such as checks, also appear to not support them.

A list of namespaced resources can be found here:

https://docs.sensu.io/sensu-go/5.14/reference/rbac/#namespaced-resource-types

Example:

    - name: Create test asset for namespace default
      sensu.sensu_go.asset:
        name: sensu-test
        url: http://www.example.com
        sha512: c9f0aff8f7f
        namespace: default

Document the update process

Our install role knows how to update the existing Sensu installation. We should write a scenario document where we guide users through a process of:

  1. fresh install,
  2. build update,
  3. version update.

Unable to install collection

Using the provided command in the readme to install the collection fails:

ansible-galaxy collection install sensu.sensu_go -p ~/.ansible/collections
- downloading role 'collection', owned by
 [WARNING]: - collection was NOT installed successfully: Content has no field named 'owner'

I then tried the --ignore-errors flag and got around the collector role error, but now have a new one:

ansible-galaxy collection install sensu.sensu_go -p ~/.ansible/collections --ignore-errors
 [WARNING]: - sensu.sensu_go was NOT installed successfully: - sorry, sensu.sensu_go was not found on https://galaxy.ansible.com

And attempting it locally from a releases download I get even another error:

ansible-galaxy collection install /Users/rgeniesse/Downloads/sensu-go-ansible-0.7.2.tar.gz -p ~/.ansible/collections --ignore-errors
 [WARNING]: - /Users/rgeniesse/Downloads/sensu-go-ansible-0.7.2.tar.gz was NOT installed successfully: this role does not appear to have a meta/main.yml file.

Using Ansible 2.8.5. Docs for collection usage I referenced:

https://docs.ansible.com/ansible/devel/user_guide/collections_using.html

Seems like collections may not be part of 2.8.5 as collection is not a verb:

ansible-galaxy --help
Usage: ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...

Please let me know if there is anything else you need.

documentation of `name` is unclear

Bug description

the module documentation is bit unclear.

In check – Manage Sensu checks, name is described as:

The Sensu object’s name.

which is unclear. it is used as a unique ID, shown in the web UI, and has some restrictions (special characters are not allowed, such as spaces).

as such, when you need to modify name, you must create another task to remove the old one, and the play fails when name contains special characters.

How to reproduce the bug

  1. rename a check, say, check to new-check, or new check.
  2. the play creates a duplicated check, or fails.

Expected result

the doc clearly states that:

  • name is an unique ID, which implies that, when you change it, you also need to remove old one.
  • how name is used
  • what restrictions it has (and a link to where you should look at)

Actual result

the doc simply says:

The Sensu object’s name.

Component versions

  • Ansible Version 2.9.7
  • Sensu Go Collection Version 1.3.1
  • Sensu Go Backend Version 5.19.1

Additional context

n/a

manage assets isnt working as expected

Bug description
when using sensu-go-ansible to manage assets it creates invalid assests

this is an asset created by sensu-go-ansible:

manage influxdb asset...

  172.18.159.51 ok: {
    "changed": false, 
    "object": {
        "builds": [
            {
                "filters": null, 
                "headers": null, 
                "sha512": "612c6ff9928841090c4d23bf20aaf7558e4eed8977a848cf9e2899bb13a13e7540bac2b63e324f39d9b1257bb479676bc155b24e21bf93c722b812b0f15cb3bd", 
                "url": "https://github.com/sensu/sensu-influxdb-handler/releases/download/3.1.2/sensu-influxdb-handler_3.1.2_linux_amd64.tar.gz"
            }
        ], 
        "filters": null, 
        "headers": null, 
        "metadata": {
            "name": "sensu-influxdb-handler", 
            "namespace": "default"
        }
    }
}

and when i go to my sensu instance, this is what i get:

$ sensuctl asset info sensu-influxdb-handler
=== sensu-influxdb-handler
Name:             sensu-influxdb-handler
Namespace:        default
URL:              
SHA-512 Checksum: 
Filters:          

all the parameters are empty.

when i tried to manually(through sensuctl) create the asset the same way ansible does that,
sensu claims to not support the 'builds' field:

resource 0: json: unknown field "builds"
Error: some resources couldn't be parsed

this is the yaml i used to create the asset manually:

type: Asset
api_version: core/v2
metadata:
  name: sensu-influxdb-handler
  namespace: default
spec:
  builds:
  - sha512: 612c6ff9928841090c4d23bf20aaf7558e4eed8977a848cf9e2899bb13a13e7540bac2b63e324f39d9b1257bb479676bc155b24e21bf93c722b812b0f15cb3bd
    url: https://github.com/sensu/sensu-influxdb-handler/releases/download/3.1.2/sensu-influxdb-handler_3.1.2_linux_amd64.tar.gz

How to reproduce the bug

  1. Run ansible playbook with the following yaml:
- name: manage influxdb asset
      asset:
        auth:
          url: https://localhost:8080
          password: '{{ sensu_password }}'
        namespace: default
        state: present
        name: sensu-influxdb-handler
        builds:
          - url: https://github.com/sensu/sensu-influxdb-handler/releases/download/3.1.2/sensu-influxdb-handler_3.1.2_linux_amd64.tar.gz
            sha512: 612c6ff9928841090c4d23bf20aaf7558e4eed8977a848cf9e2899bb13a13e7540bac2b63e324f39d9b1257bb479676bc155b24e21bf93c722b812b0f15cb3bd
      vars:
        sensu_password: SENSU_ENCRYPTED_PASSWORD
  1. look at the assets that were created...

Expected result
i would expect a valid asset to be created

Actual result
invalid asset is created with empty fields.

Component versions

  • Ansible Version 2.9.1
  • Sensu Go Collection Version: 1.0.0
  • Sensu Go Backend Version sensu-go-backend-5.14.0-6578.x86_64

Update asset module API

Currently, our asset module uses a deprecated form of payload. We did this on purpose because when we started writing the module, Sensu Go 5.9 was still supported and that version does not understand the non-deprecated API.

Now the situation changed: oldest supported Sensu Go version (5.12) has support for the new payload format, and we can safely drop the legacy API support.

We are doing this while our collection is at 0.x.y version, and the collection's API is not yet stable.

Relevant documentation is available at https://docs.sensu.io/sensu-go/5.15/reference/assets/#top-level-attributes.

Documentation for namespace syntax appears to be wrong

Bug description
Documentation here for namespaces:

https://github.com/sensu/sensu-go-ansible/blob/master/plugins/modules/namespace.py#L38-L48

shows a namespace parameter. However, when attempting to use an example like that, this error happens:

Unsupported parameters for (sensu.sensu_go.namespace) module: namespace Supported parameters include: auth, name, state

How to reproduce the bug

  1. Use the documentation example to try and add a namespace.
  2. See resulting error that namespace is not a valid parameter.

Expected result
Documentation has valid examples.

Actual result
See description above.

Component versions

  • Ansible Version 2.9.0
  • Sensu Go Collection Version 1.2.0
  • Sensu Go Backend Version 5.19 (pre-release).

Additional context
Add any other context about the problem here.

Update role metadata

Ansible Galaxy import process became a bit stricter and now some of the validations are raising warnings:

Starting import: task_id=1130, artifact_id=1130 
===== LOADING ROLE ===== 
Checking role metadata tags 
Checking role platforms 
Invalid platform: "Ubuntu-disco dingo", skipping. 
Checking role cloud platforms 
Checking role dependencies

What we need to do is go over the roles/<role>/meta/main.yml files, fix and update them (for example, Debian is currently completely missing there), and (if possible) add a test that simulates what Ansible Galaxy does when it validates the roles on import.

Change detection is not working on Sensu Go 5.19.0 and newer

Bug description
Change detection is not working on Sensu Go 5.19.0 and newer.

How to reproduce the bug
Run any playbook twice in a row against a Sensu Go 5.19.x backend.

Expected result
Second run should report all tasks as OK.

Actual result
At least some of the tasks report back changed state.

Component versions

  • Sensu Go Backend Version: 5.19.0 and newer

Additional context
The culprit for this bug is the created_by metadata field that has been added in Sensu Go 5.19.0.

Option to disable install role

On some of my deployments we're using the open source versions of sensu, either built and manually installed or compiled packages and installed from private repos. It would be nice to use these same playbooks on those systems as we do on systems using the official sensu repos and packages.

Maybe add a no_sensu_install or some other variable that can be defined when calling the backend or agent roles that then skips the calls to the install role.

Update module metadata

Before we release 1.0, we need to unify the collection's metadata. We need to make sure all of the modules have this piece of at the top of the file:

ANSIBLE_METADATA = {
    "metadata_version": "1.1",
    "status": ["stableinterface"],
    "supported_by": "certified",
}

Also, each DOCUMENTATION block must contain version_added: 1.0 field.

`user` resource is not idempotent

Bug description

the resource always returns changed=true.

How to reproduce the bug

  1. Create a user with the resource in a playbook
  2. Run the playbook again

Expected result

If the resource attributes are same, it returns changed=false.

Actual result

the resource returns changed=true.

Component versions

  • Ansible Version 2.9.7
  • Sensu Go Collection Version 1.3.1
  • Sensu Go Backend Version 5.19.1

Additional context

this prevents tests with test-kitchen from pass.

Update the module names in documentation

Documentation should use a fully qualified module, plugin, and role names by default. The only exception to this rule are samples that contain a collections: [ sensu.sensu_go ] directive.

Keeping release process simple yet efficient

Now that we are starting to release our work to the Ansible Galaxy, it would be time to define how we track those same releases in our git repo.

I would suggest the following convention:

  1. master branch contains the latest and greatest in our collection.
  2. stable branch points to the most recent tag that we created.

When we create a new collection release, we tag the current master's HEAD commit with an appropriate version number and update the stable branch.

The main reason for doing this is ensuring that our collection is working as expected without having to test every release we ever made. Under this scenario, we would run daily tests against master and stable branches.

/cc @miha-plesko @aljazkosir @matejart

Get documentation fragments and common argument specifications back in sync

At the moment, common argument specifications in plugins/module_utils/arguments.py and documentation in plugins/doc_fragments/*.py are out of sync a bit. While not being much of a problem right now, getting them back in sync would allow us to remove some of the duplicated documentation from our modules.

Note that this should probably be fixed after we convert all of the remaining sensu_go_ prefixed modules in order to avoid sanity check having a mental breakdown.

Feature Request: diff of the objects

It would be very handy to have support for --diff option.

Implementation is quite simple (pseudocode):

import json

def pretty_print_object(obj):
    return json.dumps(obj, indent=2)

diff = dict(before='', before_header='', after='', after_header='')

diff['before'] = pretty_print_object(old_state)
diff['after'] = pretty_print_object(new_state)

module.exit_json(changed=changed, diff=diff, ...)

Setting up a SensuGo cluster Failed

Thank you for sharing your playbook and I really appreciate your great work.

I have tried setting up a SensuGo cluster using your Ansible role ver 0.7.6.
I created the following simple playbook to confirm whether I can make a SensuGo cluster.

Target Nodes (All nodes is Ubuntu 18.04 & lxc container)

Node1: ipv4_address: 10.5.126.31, hostname: sensugo-backend-test1
Node2: ipv4_address: 10.5.126.32, hostname: sensugo-backend-test2
Node3: ipv4_address: 10.5.126.33, hostname: sensugo-backend-test3

Current Directory

.
├── backend.yml
└── hosts

hosts


[backends]
10.5.126.31
10.5.126.32
10.5.126.33


backend.yml

---
- hosts: backends
  become: true
  roles:
    - role: sensu.sensu_go.backend
      backend_config:
        etcd-advertise-client-urls: "http://{{ ansible_default_ipv4.address }}:2379"
        etcd-listen-client-urls: "http://{{ ansible_default_ipv4.address }}:2379"
        etcd-listen-peer-urls: "http://0.0.0.0:2380"
        etcd-initial-cluster: "sensugo-backend-test1=http://10.5.126.31:2380, sensugo-backend-test2=http://10.5.126.32:2380, sensugo-backend-test3=http://10.5.126.33:2380"
        etcd-initial-advertise-peer-urls: "http://{{ ansible_default_ipv4.address }}:2380"
        etcd-initial-cluster-state: "new"
        etcd-initial-cluster-token: ""
        etcd-name: "{{ ansible_hostname }}"

I ran the following command at current directory.

$ ansible-playbook -i hosts backend.yml -k -K

However, the following error occurs:

RUNNING HANDLER [backend : Restart backend] ************************************
fatal: [10.5.126.32]: FAILED! => {"changed": false, "msg": "Unable to restart service sensu-backend: Job for sensu-backend.service failed.\nSee \"systemctl status sensu-backend.service\" and \"journalctl -xe\" for details.\n"}
fatal: [10.5.126.33]: FAILED! => {"changed": false, "msg": "Unable to restart service sensu-backend: Job for sensu-backend.service failed.\nSee \"systemctl status sensu-backend.service\" and \"journalctl -xe\" for details.\n"}

sensu-backend seems to work only on sensugo-backend-test1

root@sensugo-backend-test1:~# service sensu-backend status
● sensu-backend.service - The Sensu Backend service.
   Loaded: loaded (/lib/systemd/system/sensu-backend.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-11-08 11:39:32 UTC; 1s ago
root@sensugo-backend-test2:~# service sensu-backend status
● sensu-backend.service - The Sensu Backend service.
   Loaded: loaded (/lib/systemd/system/sensu-backend.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2019-11-08 11:38:51 UTC; 18s ago

I saw each error logs by journalctl.

Nov 08 11:39:37 sensugo-backend-test1 sensu-backend[3698]: {"component":"etcd","level":"warning","msg":"health check for peer 6fa8bca0452c40e1 could not connect: dial tcp 10.5.126.32:2380: connect: connection refused (prober \"ROUND_TRIP
Nov 08 11:39:37 sensugo-backend-test1 sensu-backend[3698]: {"component":"etcd","level":"warning","msg":"health check for peer 9d4769c999212de8 could not connect: dial tcp 10.5.126.33:2380: connect: connection refused (prober \"ROUND_TRIP
Nov 08 11:39:39 sensugo-backend-test1 sensu-backend[3698]: {"component":"etcd","level":"error","msg":"publish error: etcdserver: request timed out","pkg":"etcdserver","time":"2019-11-08T11:39:39Z"}
Nov 08 11:38:51 sensugo-backend-test2 sensu-backend[1247]: {"component":"sensu-enterprise","error":"error starting etcd: couldn't find local name \"sensugo-backend-test2\" in the initial cluster configuration","level":"fatal","msg":"error executing sensu-backend","time":"2019-11-08T11:38:51Z"}

sensugo-backend-test3 is the same logs as sensugo-backend-test2.

Each configuration file generated by Ansible is as follows:

state-dir: "/var/lib/sensu/sensu-backend"

etcd-advertise-client-urls: http://10.5.126.31:2379
etcd-initial-advertise-peer-urls: http://10.5.126.31:2380
etcd-initial-cluster: sensugo-backend-test1=http://10.5.126.31:2380, sensugo-backend-test2=http://10.5.126.32:2380,sensugo-backend-test3=http://10.5.126.33:2380
etcd-initial-cluster-state: new
etcd-initial-cluster-token: ''
etcd-listen-client-urls: http://10.5.126.31:2379
etcd-listen-peer-urls: http://0.0.0.0:2380
etcd-name: sensugo-backend-test1
state-dir: "/var/lib/sensu/sensu-backend"

etcd-advertise-client-urls: http://10.5.126.32:2379
etcd-initial-advertise-peer-urls: http://10.5.126.32:2380
etcd-initial-cluster: sensugo-backend-test1=http://10.5.126.31:2380, sensugo-backend-test2=http://10.5.126.32:2380,sensugo-backend-test3=http://10.5.126.33:2380
etcd-initial-cluster-state: new
etcd-initial-cluster-token: ''
etcd-listen-client-urls: http://10.5.126.32:2379
etcd-listen-peer-urls: http://0.0.0.0:2380
etcd-name: sensugo-backend-test2
state-dir: "/var/lib/sensu/sensu-backend"

etcd-advertise-client-urls: http://10.5.126.33:2379
etcd-initial-advertise-peer-urls: http://10.5.126.33:2380
etcd-initial-cluster: sensugo-backend-test1=http://10.5.126.31:2380, sensugo-backend-test2=http://10.5.126.32:2380,sensugo-backend-test3=http://10.5.126.33:2380
etcd-initial-cluster-state: new
etcd-initial-cluster-token: ''
etcd-listen-client-urls: http://10.5.126.33:2379
etcd-listen-peer-urls: http://0.0.0.0:2380
etcd-name: sensugo-backend-test3

I feel that there is no problem with the configuration files.
I have no idea what caused this failure.
By the way, in the case of one sensu-backend, it works without problems.
I would appreciate any advice on this issue.
Thank you for reading.

Improve config file pemissions

The files /etc/sensu/agent.yml (agent role, main task) and /etc/sensu/backend.yml (backend role, main task) should be readable for sensu only because they can contain credentials (e.g. username/password for API).

With the current default permissions, these files are public readable.

Missing Debian.yml in for install role

Bug description
Missing roles/install/vars/Debian.yml

Trying to run agent install against a debian host and the playbook errors out.

How to reproduce the bug

  1. fire up debian stretch vagrant host
  2. ansible-playbook -i inventory.yaml playbook.yaml

Expected result
playbook should run
A clear and concise description of what you expected to happen.

Actual result

TASK [install : Include distro-specific vars (Debian)] ******************************************************************************************************************
fatal: [192.168.50.11]: FAILED! => {"ansible_facts": {}, "ansible_included_var_files": [], "changed": false, "message": "Could not find or access 'Debian.yml'\nSearched in:\n\t/home/jspaleta/.ansible/collections/ansible_collections/sensu/sensu_go/roles/install/vars/Debian.yml\n\t/home/jspaleta/.ansible/collections/ansible_collections/sensu/sensu_go/roles/install/Debian.yml\n\t/home/jspaleta/.ansible/collections/ansible_collections/sensu/sensu_go/roles/agent/vars/Debian.yml\n\t/home/jspaleta/.ansible/collections/ansible_collections/sensu/sensu_go/roles/agent/Debian.yml\n\t/home/jspaleta/.ansible/collections/ansible_collections/sensu/sensu_go/roles/install/tasks/apt/vars/Debian.yml\n\t/home/jspaleta/.ansible/collections/ansible_collections/sensu/sensu_go/roles/install/tasks/apt/Debian.yml\n\t/home/jspaleta/sources/orgs/sensu/sensu-go-ansible/docs/examples/scenarios/monitoring_hosts/vars/Debian.yml\n\t/home/jspaleta/sources/orgs/sensu/sensu-go-ansible/docs/examples/scenarios/monitoring_hosts/Debian.yml on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"}

Component versions

  • Ansible Version: 2.9.3
  • Sensu Go Collection Version 1.2.0
  • Sensu Go Backend Version 5.16.1

Additional context
Using playbooks and Vagrantfiles from scenario-docs branch
Adding Debian.yml at location indicated in the error solves the problem.

Consider splitting some modules

There are some modules that should probably get split into more modules in order to keep them simple and with manageable set of input parameters. For example the

sensu_go_handler

(link)

module. There are 3 major handler types available as per https://docs.sensu.io/sensu-go/5.11/reference/handlers/#how-do-sensu-handlers-work:

  • pipe handlers
  • TCP/UDP handlers
  • handler set

Each of those major types supports slightly different set of input parameters. So it seems more user-friendly to provide three modules to do the job:

sensu_go_pipe_handler
sensu_go_socker_handler
sensu_go_handler_set

Handler module is just one example of a currently too complex module. There is also sensu_go_check module with two or three dozens of input parameters that should probably be somehow split as well, if possible...

issue when authenticated to https://localhost:8080

Bug description
our sensu api server is configured to work on https://localhost:8080
when i try to use sensu-go-ansible, it cant verify the client certificate and throws the following error:

Executing playbook basic_checks.yml

- us-west-2 on hosts: us-west-2 -
Gathering Facts...
  MY_HOST_IP ok
cpu_load...
  MY_HOST_IP failed: {
    "changed": false, 
    "msg": "GET request failed: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)"
}

How to reproduce the bug

  1. configure sensu backend to use https on api:
---
#
# Ansible managed
#
api-url: https://localhost:8080
cert-file: /etc/ssl/certs/server/Server.pem
key-file: /etc/ssl/certs/server/Server-key.pem
state-dir: /var/lib/sensu/sensu-backend
trusted-ca-file: /etc/ssl/certs/ca/ca.pem
log-level: error
  1. use the ansible collection to manage sensu

Expected result
i expect to have the ability to provide a path to the certificate that will be used during the api call to sensu
and have the ability to disable certificate validation as part of the 'auth' util.

Actual result
now i dont have any control over ssl authentication

Component versions

  • Ansible Version: 2.9.1
  • Sensu Go Collection Version 1.0.0
  • Sensu Go Backend Version: 5.14.1

Additional context

i would expect a yaml file to look this way:
where u have the ability to turn off certificate validation on the auth section
and have the ability to pass client cert.

tasks:
    - name: cpu_load
      check:
        auth:
          url: https://localhost:8080
          password: '{{ sensu_password }}'
          validate_certs: False
          #client_cert: PATH_TO_CLIENT_CERT
        state: present
        timeout: 10
        namespace: default
        subscriptions: all
        output_metric_handlers: ["influx-db"]
        output_metric_format: nagios_perfdata
        name: cpu_load
        command: check_load -w 15,10,5 -c 30,25,20
        interval: 180
      vars:
        sensu_password: PASSWORD

to achieve that, the options 'validate_certs' and 'client_cert' should be passed to to 'request' method in file: sensu_go/plugins/module_utils/http.py
and later on the open_url method
for example:

raw_resp = open_url(
            method=method,validate_certs=False, url=url, data=data, headers=headers, **kwargs
        )

Prepare end-user documentation

NOTE: @tadeboro will (ab)use this issue for storing notes about the documentation. You have been warned.

Sections that we need to prepare are:

  • quickstart,
  • installation,
  • a few scenario guides (simple installation, cluster setup),
  • module API documentation (create a nicer layout),
  • development guides (partially done).

Agent role isn't useful w/out being able to provision w/ subscriptions

As part of the agent role, we're not able to provide subscriptions when provisioning an agent. This doesn't make the role too terribly useful. It'd be nice for this role to follow similar conventions that are laid out with the backend role (e.g., like backend_config, there should be agent_config).

Fix validation and idempotence checks in role module

In #88 we realized that integration tests verifying idempotence of cluster role creation fail when the order of verbs, resources or resource_names associated with a role rule is different compared to when the role was created. This resulted in creation of a new cluster role with same rules but different ordering of enclosed verbs/resources/resource_names.

The role module, i.e. the sister module of cluster_role needs to be synchronized with changes in cluster_role, which include:

  • providing a custom comparator function to resolve the above issue, and
  • additional validation check to ensure rules list is non-empty, to avoid a Bad Request error on the Sensu backend.

Feature request: Ability to pick see a new package based on build number

I've gone ahead and went with a blank issue as this is a FR and not a bug. Let me know if anything more is needed here.

As a follow up to being able to have the repository channel be configurable, we have ran into another scenario where it would be beneficial to call out the build number to look for inside the package.

During the Sensu Go QA process for a new release candidate, we are using this Ansible collection to upgrade a long running instance of Sensu Go to mimic customer environments. This lets us both look for possible issues that may not be seen on environments spun up just for QA and also learn about the Ansible collection for supporting customers that are or may eventually use it.

When we upgrade our long running instance as part of the QA process, if bug is found, currently only the version of the package is looked at by Ansible. The new release candidate only has the build number changed as fixes are put in, so Ansible doesn't see anything "new". While not all bugs will warrant another upgrade of this long running instance, as it stands I have to downgrade to the old version and re-upgrade to the new build to get a new release candidate installed.

Is it possibly to have Ansible, either in the collection or in Ansible core, to detect the build number of the package? It would appear for at least yum the release field is what contains this:

Name        : sensu-go-backend
Arch        : x86_64
Version     : 5.15.0
Release     : 7782
Size        : 35 M
Repo        : installed
From repo   : sensu_stable
Summary     : Sensu Go Backend
URL         : https://sensu.io
License     : Proprietary
Description : Sensu Go Backend

I took a quick look around and only found this area to have that added:

https://github.com/sensu/sensu-go-ansible/blob/master/roles/install/tasks/main.yml#L10-L17

But I don't know how you would default the build number or maybe you would need a conditional that if it is null, don't look at it. Also don't know if there are python things to make this worth either.

Unable to create UDP handler using sensu_go_handler

I'm unable to create a UDP handler using sensu_go_handler:

Playbook:

    - name: create sensu core gateway handler
      sensu_go_handler:
        auth: "{{ sensu_auth }}"
        name: sensu-core-gateway
        type: udp
        socket_host: localhost
        socket_port: "{{ 4446 | int }}"
        filters:
          - sensu-go-only

Error:

TASK [create sensu core gateway handler] ***************************************************************************************************************************************************************************************************************************************************
fatal: [******]: FAILED! => {"changed": false, "msg": "put failed: Bad Request {\"message\":\"json: cannot unmarshal string into Go struct field HandlerSocket.socket.port of type uint32\",\"code\":1}"}

Environment:

  • ansible: 2.9.0
  • sensu.sensu_go: 0.7.8
  • sensu go: 5.14.2-7022

Without typecast of the port number I get the same error and the additional warning: The value 4446 (type int) in a string field was converted to u'4446' (type string). If this does not look like what you expect, quote the entire value to ensure it does not change.

COmparison of single-build and multi-build assets fails

Bug description
If the backend contains a single-build asset that we would like to replace with a muti-build asset, the update process will fail when comparing an existing and replacement object.

How to reproduce the bug

  1. Create a single-build asset on the backend.
  2. Try replacing it with a multi-build asset using the asset or bonsai_asset module.

Expected result
A muti-build asset should replace the single-build one.

Actual result
The replacement fails because it cannot compare the single- and multi-build assets.

Component versions

  • Ansible Version: >= 2.9
  • Sensu Go Collection Version: >= 1
  • Sensu Go Backend Version: >= 5.16

Initialize backend fails in check mode

Bug description
When running through the backend playbook in ansible checkmode Initialize backend fails because init_command_test is undefined.

How to reproduce the bug

  1. Run the command ansible-playbook -i inv ... -C.

Expected result
This step should just skip like the Check for sensu-backend init command does

Actual result
Ansible exits prematurely

FAILED! => {"msg": "The conditional check 'init_command_test.rc == 0' failed. The error was: error while evaluating conditional (init_command_test.rc == 0): 'dict object' has no attribute 'rc'\n\nThe error appears to be in '.../collections/ansible_collections/sensu/sensu_go/roles/backend/tasks/main.yml': line 80, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Initialize backend\n  ^ here\n"}

Component versions

  • Python Version: 3.6.9
  • Ansible Version: 2.9.6
  • Sensu Go Collection Version: 1.3.0

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.