[dev.icinga.com #9332] Send custom attributes/groups/etc from satellite to master for node update-config

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/9332

Created by adegtyarev on 2015-05-28 14:12:36 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2017-01-14 13:08:23 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

---

Variables that set on satellite side are not passed to master:

satellite:

# icinga2 object list --type host
 ...
  * vars
    * check_pgsql = 1
      % = modified in '/etc/icinga2/conf.d/hosts.conf', lines 7:3-7:22
    * notification
      * sms = 1
        % = modified in '/etc/icinga2/conf.d/hosts.conf', lines 10:3-10:27
    * os = "Linux"
 ...

master:

# icinga2 object list --type host
 ...
  * vars
    * notification
      * mail
        % = modified in '/etc/icinga2/conf.d/satellite.conf', lines 2:3-4:3
        * groups = [ "infrastructure" ]
 ...

This eventually leads to some lacks:

• Unable to use groups according to vars set on satellites:

object HostGroup "linux-servers"{
  display_name = "Linux Servers"
  assign where host.vars.os == "Linux"
}

No satellite host will appear in this group regardless host.vars.os is set on satellite or not. This could probably workarrounded with satellite's hosts definition directly on master, but it this case the idea of satellites looks not so much attractive..

• Unable to use notifications on master based on host/service vars from satellites:

apply Notification "sms" to Service {
    import "sms-service-notification"
    assign where host.vars.notification.sms
}

As long as host.vars.* unset on master, no notification will be applied to satellite's services. To make this notifications work, notifications on satellites required to be enabled, which is not always possible.

Would be a nice feature if variables from satellites gets transferred to master as well.

---

Parent Task: #13257

[icinga-migration]

Updated by mfriedrich on 2015-06-09 08:07:18 +00:00

• Relates set to 8250

[icinga-migration]

Updated by mfriedrich on 2015-06-17 20:39:25 +00:00

• Duplicated set to 9440

[icinga-migration]

Updated by mfriedrich on 2015-06-18 09:12:51 +00:00

• Category set to Cluster
• Status changed from New to Assigned
• Assigned to set to mfriedrich

[icinga-migration]

Updated by mfriedrich on 2015-06-18 11:38:45 +00:00

• Subject changed from Pass variables from satellite to master to Send custom attributes from satellite to master for node update-config

[icinga-migration]

Updated by mfriedrich on 2015-06-23 13:26:20 +00:00

• Target Version set to Backlog

[icinga-migration]

Updated by mfriedrich on 2015-09-07 09:31:53 +00:00

• Subject changed from Send custom attributes from satellite to master for node update-config to Send custom attributes/groups/etc from satellite to master for node update-config

[icinga-migration]

Updated by mfriedrich on 2015-09-09 08:13:45 +00:00

• Relates set to 10077

[icinga-migration]

Updated by mfriedrich on 2015-09-12 09:03:10 +00:00

• Status changed from Assigned to New
• Assigned to deleted mfriedrich

I've looked into the code for a while now, and I am afraid this feature request involves quite a few incompatible changes:

1. the repository contains a list of services attached to a host as key inside this dictionary. adding more attributes would require us to change the structure, e.g.

   {
   "hostname": {
   "attrs": {
   "groups": [ ...]
   },
   "templates": [...],
   "services": {
   "servicename": {
   "attrs": {
   "vars": {
   "os": "..."
   },
   },
   "templates": [ ... ]
   },
   "service2": ...
   }
   }
   },
   "host2": ....

   }

2. That involves rewriting the node update-config code in larger parts.

3. The repository handler on the clients must be rewritten to dump more attributes.

4. This won't be compatible with older versions - so you can't run a 2.4 master with 2.3 clients

5. The repository config writer must be made aware of these new items. At this time it is not as robust as the one we've implementing for the API configuration storage.

I personally see this feature after 2.4 and a general design overhaul how to deal with clients and their local configuration and/or service discovery. Imho the API parts will be a better base than the repository is now.

[icinga-migration]

Updated by mfriedrich on 2015-09-12 09:05:46 +00:00

• Relates set to 8213

[icinga-migration]

Updated by dawe on 2016-03-04 12:00:52 +00:00

It would be really nice to implement this, any plans to do that in the near future ?

btw thanks for working hard on icinga,it's really a great work. it's very useful and essential solution.

Thanks !

David

[icinga-migration]

Updated by mfriedrich on 2016-03-04 17:13:51 +00:00

• Relates set to 9438

[icinga-migration]

Updated by mfriedrich on 2016-03-18 14:37:45 +00:00

No it is not planned to implement that in the near future as this will involve changes to how update-config works.

[icinga-migration]

Updated by mfriedrich on 2016-03-18 14:37:50 +00:00

• Relates set to 10980

[icinga-migration]

Updated by mfriedrich on 2016-03-18 17:29:42 +00:00

• Relates set to 10054

[icinga-migration]

Updated by bdhaeyer on 2016-05-31 15:57:39 +00:00

Hello Everyone,

I found a way to overcome this by reconstructing the custom attributes using conditional tests in the "satellite template" on the master. On the template you can test the few data you get, to put back the custom attributes. If your hostnames / services have naming conventions, it's quite easy.

It's a dirty way but it works for now.

Any plan for this feature to be implemented? Despite working well, my script looks like having been abused :-)

Thanks !

Benjamin

EDIT : i looked into the code, and indeed this "trick" works because of line 294 and 295 in "nodeupdateconfigcommand.cpp" (https://github.com/Icinga/icinga2/blob/master/lib/cli/nodeupdateconfigcommand.cpp#L294), It automatically set the default satellite template. And this is this specific template i modified with the nasty conditions around the host / services names. After reading a bit of its content, i came to the same conclusion as post #8, it will need more than few lines to fix this : needs to search the attributes, eventually pass also the templates from satellite to master, check if the template isn't already existing, check if the attributes aren't garbage... Doesn't look like an easy implementation. On another side, you're totally right, the handler need to dump more attributes, which needs a partial rewrite too. If i had more time, i could try to contribute, but unfortunately my schedule is completly full. Thanks again for your analysis and the good job! Can't wait for someone to have a look at it :-)

[icinga-migration]

Updated by gbeutner on 2016-08-27 19:41:05 +00:00

• Duplicated set to 12569

[icinga-migration]

Updated by GreenRover on 2016-08-29 04:23:00 +00:00

dnsmichi: I personally see this feature after 2.4

Ok actually we are on 2.4 do you have any time line when this feature could be implemented?

[icinga-migration]

Updated by mfriedrich on 2016-11-18 17:10:45 +00:00

• Relates set to 13255

[icinga-migration]

Updated by mfriedrich on 2016-11-23 14:57:03 +00:00

• Target Version deleted Backlog

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:07:49 +00:00

• Relates deleted 8250

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:07:53 +00:00

• Relates deleted 10077

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:07:56 +00:00

• Relates deleted 8213

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:07:59 +00:00

• Relates deleted 9438

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:03 +00:00

• Relates deleted 10980

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:06 +00:00

• Relates deleted 10054

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:09 +00:00

• Relates deleted 13255

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:12 +00:00

• Duplicated deleted 9440

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:15 +00:00

• Duplicated deleted 12569

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:23 +00:00

• Parent Id set to 13257

[dnsmichi]

#4799