icinga2_config_host as child of icinga2_objects

[gianmarco-mameli]

Hello,
I'm trying to figure why the variable "icinga2_config_host" is used as a child of the icinga2_objects variable in the 'icinga2' role.
Let me explain why: as you all known the ansible variable inheritance is convenient to override variables for hosts and groups, so in my case I have a generic icinga2_objects variable at the group level 'all' that apply to all my hosts managed by ansible and monitored by icinga, a more complete icinga2_objects variable declared at group level for my 'masters' and the last icinga2_objects at 'master2' level. With that method in my variables is not convenient and I cannot specify a 'icinga2_config_host' as child for all objects, so the role doesn't work.
I'm able to use my vars with a slight mod to the role in the file 'objects.yml' like this

# - name: collect all config objects for myself
#   set_fact:
#     tmp_objects: "{{ tmp_objects| default([]) + lookup('list', hostvars[item]['icinga2_objects'][icinga2_config_host]) }}"
#   with_items: "{{ groups['all'] }}"
#   when: hostvars[item]['icinga2_objects'][icinga2_config_host] is defined

- name: collect all config objects in play vars
  set_fact:
  #   tmp_objects: "{{ tmp_objects| default([]) + lookup('list', icinga2_objects[icinga2_config_host]) }}"
  # when: vars['icinga2_objects'][icinga2_config_host] is defined
    tmp_objects: "{{ tmp_objects| default([]) + lookup('list', icinga2_objects) }}"
  when: vars['icinga2_objects'] is defined

So mine is more a question that an issue, why is designed to gather all config objects and all play vars with a host as child of objects?
I hope that I explained well my perplexity. If my mod is right to you I can submit a PR to better analyze and test the behavior

Thanks

[mkayontour]

Hi thanks for the question and I think you found a bug as well. The motive of this icinga2_objects is that you can define the variable anywhere and don't deploy the whole monitoring configuration everywhere.

Let's take a group for our master hosts, every master has kind of the same configuration but different names. But the configuration which is deployed, should be synced over the icinga cluster sync. In this case we can use the variables in the same play and only deploy monitoring configuration on the config master.

icinga2_objects:
  config_master.fqdn:
    - name: host1
       type: Host
       [...]

Thats the first code of block. You can also define for a specific satellite in his own host_vars, some lokal configuration.

On the other hand, the second block should enable you to use the icinga2_objects in the way that Ansible normally uses variables. You can define the variable and overwrite it in different files. And there is an issue, I think the following line should be changed:

- name: collect all config objects in play vars
  set_fact:
    tmp_objects: "{{ tmp_objects| default([]) + lookup('list', icinga2_objects[icinga2_config_host]) }}"
-  when: vars['icinga2_objects'][icinga2_config_host] is defined
+  when: vars['icinga2_objects'][icinga2_config_host] is not defined

Because then if there's no variable with the config host name defined, the "normal" method will be used.

Can you try to change the line and verify it is working?

[gianmarco-mameli]

Hi, thanks for the explanation, tomorrow I can test this mod and I tell you the result

[gianmarco-mameli]

Hi, I tried but with your suggestion the task fails, so i noticed it can work removing also the [icinga2_config_host] on the previous line, so the task became

- name: collect all config objects in play vars
   set_fact:
      tmp_objects: "{{ tmp_objects| default([]) + lookup('list', icinga2_objects) }}"
   when: vars['icinga2_objects'][icinga2_config_host] is not defined

let me know if I'm right

[mkayontour]

Sorry, yes this is my fault - indeed if icinga2_config_host is not defined, we should only use icinga2_objects as variable.

If this is what you are looking for, I would create a PR, documentation and fix it.

[gianmarco-mameli]

No problem, the task that I pasted in my previous comment is working as expected. If you prefer I can send the PR for you, I already have the project forked.

Thanks

[mkayontour]

If you have everything already prepared this would be helpful. Thank you :)

[gianmarco-mameli]

Hi, I've submitted PR #255