Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate facts for all sites #15

Closed
wants to merge 2 commits into from
Closed

Conversation

ganto
Copy link
Member

@ganto ganto commented Jun 25, 2016

Currently the checkmk_server role only allows you to manage one site. However, you may have multiple playbooks for multiple sites or manually manage other sites. If possible also generate facts for other sites, so that the checkmk_agent role can relate to them (see debops-contrib/ansible-checkmk_agent#15).

@ganto
Copy link
Member Author

ganto commented Jul 12, 2016

Fortunately I was hesitating with merging this. After playing around with it, I found out this doesn't work at all. The lookup plugin is executed on the Ansible controller which on my development machine used to be the same as the target server. If they are separate the facts template doesn't contain any valuable information. So this PR doesn't work as originally intended.

@ypid: I guess I need some help finding a good solution here. What I'm trying to do:

  • Provide role facts about the available Check_MK sites. Especially interesting would be the SSH public key of the corresponding site user, so that an agent can read it from the facts (Integrate agent setup with checkmk_server role ansible-checkmk_agent#14) and set it by itself.
  • If possible this should also work for manually created sites or sites defined in a separate inventory to support multiple sites per host, therefore the site names should be queried on the system and not taken from the inventory.
  • I tried to solve this by attempting to define dictionary facts with multiple keys. But this didn't work. Is this possible at all with Ansible?

Optionally, I could do a delegate_to task in the agent role, which would query the SSH key specifically for the site it wants to register. Still, I find this solution somehow less appealing.

Any ideas, suggestions?

@ypid
Copy link
Member

ypid commented Jul 12, 2016

Lets see if I can help you here.

Optionally, I could do a delegate_to task in the agent role, which would query the SSH key specifically for the site it wants to register. Still, I find this solution somehow less appealing.

Hm, that seems to be the most straight forward way to do it. The second way would be to put the public key(s) on the monitoring servers in Ansible facts and play with accessing those facts from the nodes to monitor. That should work but I have never tried that. It might require facts caching or running against the monitoring servers in the same play.

If possible this should also work for manually created sites

Should be possible. I am not up-to-date with all the fancy stuff in Check_MK and OMD but I guess you can access the SSH public keys using a somewhat deterministic file path? Then you can just put that in Ansible facts.

As for how to do it. You can cat the public key using the command module and then put it in the facts file.

I tried to solve this by attempting to define dictionary facts with multiple keys. But this didn't work. Is this possible at all with Ansible?

If it can be expressed in JSON or YAML, then you can set it as Ansible facts. You might have to play a bit with Jinja to make it work but there is always a way. Maybe using a list like in:

---

_site_name:
  ssh_publickey:
    - pub key
    - pub key

would make sense. You can just append to a list in Jinja.

@ypid
Copy link
Member

ypid commented Jul 12, 2016

For the Jinja question. You could use a tmp variable to get started?

(Untested:)

{% set tmp = {{'ssh_publickey': _pubkey}) %}
{% set _ = tmp.update({'ssh_publickey2': _pubkey2}) %}
{% set _ = _site_facts.update({_site_name: tmp}) %}

@ganto
Copy link
Member Author

ganto commented Jul 25, 2016

It's not trivial to make my idea work with Ansible set_fact and Jinja2. So I first concentrate on integrating server and agent all being managed by DebOps and maybe comeback to this later again.

@ganto ganto closed this Jul 25, 2016
@ganto ganto deleted the sites branch August 21, 2016 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants