[WIP] Complete rework of the role to simplify distributed site setup

[ganto]

This is an elaboration on how to solve the setup of distributed sites as discussed in #45. It is still a work in progress but mostly functional.

I choose a new approach in setting up and connecting the distributed sites. Previously the host running the site was responsible for configuring and setting up the site. However, the chosen approach was limited to one site per server and required a cumbersome manual configuration for connecting multiple sites to a distributed site setup (check e.g. #41).

This PR introduces a new way. The distributed site setup is mainly configured on the host running the master site. Like this it will hold most information required to setup and synchronized with the slave sites. This makes it mostly transparent if the site is running on the master site server or another one.

Those changes required an adjustment of the checkmk_server__distributed_sites format. Now it will accept a list of master (and their slave) sites. The simplest possible configuration for a two server setup (server01/server02), where server01 is running the master and server02 a slave site, would look as following. Enable the debops-contrib.checkmk_server role on both servers, then set the following values in the inventory:

• Define a slave site in the host_vars/server01:

  checkmk_server__distributed_sites:
  - name: 'slave'
  delegate_to: 'server02'

• Disable the default site in the host_vars/server02:

  checkmk_server__site: False

Eventually run the provided checkmk_server.yml playbook on both servers. This would create the default site on server01 and add a slave site (called slave) on the second server. The entire user account/password, URL, network port, synchronization configuration is completely transparent to the user.

Technically this is solved by a checkmk_server/env sub-role which is mostly responsible for generating a facts file on server01 and server02 which then can be used by the playbook and subsequent tasks for their individual site configuration. Additionally a lot of tasks which need on server02 which need in-depth knowledge about server01 or the master site are triggered from the master server via delegate_to tasks.

The chosen setup further allows an easy solution for fixing #44. However, when testing and investigation Check_MK in the course of writing this code, I found another maybe much more elegant way to handle the site config synchronization. More on that later...

In the next few days I will cleanup the documentation, fix the still missing debops.apache dependency, try to cleanup the macros and leverage the official DebOps macros and provide a simple Vagrant setup to simplify testing and debugging for me and potential users. Stay tuned.

[ganto]

I rebased my patchset on current master to include all the recent feature and documentation updates.

[ganto]

In the mean time I achieved to satisfy the repospec test-suite. It will pass when being run from my own repository (which still misses 466e8bd95b55ae323d3d1a1e4d347306adbce176). The results can be found at travis-ci.org: ganto/checkmk_server (branch distributed-rework). Once this PR is ready for merge, I will update debops/test-suite which should make it pass here too.

The etc/ansible/facts.d/checkmk_server.j2 template is cleaned up now. Next will be the lookup/checkmk_server__sites.j2 which again might shake up the entire configuration layout a bit.

[ypid]

@ganto Do you know when you can finish this PR? I would still like to look into the latest version of the role and make changes to it :)

[ganto]

@ypid What changes to you have in mind?

At the moment my development activity on this role is stalled. I realized that my approach would also write down the login secrets for the site synchronization as clear text local ansible facts. That definitely shouldn't be. :-1:

Maybe I find again some time to work on it in the next few months...

[ypid]

What changes to you have in mind?

What ever is necessary. I would just like to have a clean state of the role so that I could propose bigger changes/reworks if I want to without causing pain with rebasing or stuff like this.