With v1.0, Icinga Notifications will require a different event structure. This is about changes to how rules are evaluated.
Icinga/icinga-notifications#406 introduces attribute negotiation. Each event is expected to describe the relations an object has. This moves actual rule evaluation back to Icinga Notifications.
Icinga DB is not expected to always include all relations, let alone all attributes of one. The default should be a sane default. (e.g. The object itself and it's own groups. Attributes for each: name and display_name)
During evaluation of a rule filter, Icinga Notifications may detect that a relation or one of its attributes is missing. In this case, it will respond with a list of missing components in the form of a JSONPath. This may look like this:
Request:
{
"type": "attribute negotiation",
"attributes": [
"servicegroups",
"host.address"
]
}Response: (Showing a full update)
{
"relations": {
"host": {
"name": "web-1-a",
"display_name": "Web 1 A",
"address": "10.1.8.25"
},
"hostgroups": [
{
"name": "web-servers",
"display_name": "Web Servers"
}
],
"servicegroups": [
{
"name": "http-services",
"display_name": "HTTP Services"
}
]
}
}If Icinga DB is configured to always include particular relations, it can signal Icinga Notifications that these are complete and cannot be updated by using a request header: X-Icinga-Complete-Relations: host.vars, services[*].vars
Though, the actual protocol isn't set in stone yet. This should be streamlined during implementation and reconciled with whoever implements Icinga/icinga-notifications#406.
With v1.0, Icinga Notifications will require a different event structure. This is about changes to how rules are evaluated.
Icinga/icinga-notifications#406 introduces attribute negotiation. Each event is expected to describe the relations an object has. This moves actual rule evaluation back to Icinga Notifications.
Icinga DB is not expected to always include all relations, let alone all attributes of one. The default should be a sane default. (e.g. The object itself and it's own groups. Attributes for each:
nameanddisplay_name)During evaluation of a rule filter, Icinga Notifications may detect that a relation or one of its attributes is missing. In this case, it will respond with a list of missing components in the form of a JSONPath. This may look like this:
Request:
{ "type": "attribute negotiation", "attributes": [ "servicegroups", "host.address" ] }Response: (Showing a full update)
{ "relations": { "host": { "name": "web-1-a", "display_name": "Web 1 A", "address": "10.1.8.25" }, "hostgroups": [ { "name": "web-servers", "display_name": "Web Servers" } ], "servicegroups": [ { "name": "http-services", "display_name": "HTTP Services" } ] } }If Icinga DB is configured to always include particular relations, it can signal Icinga Notifications that these are complete and cannot be updated by using a request header:
X-Icinga-Complete-Relations: host.vars, services[*].varsThough, the actual protocol isn't set in stone yet. This should be streamlined during implementation and reconciled with whoever implements Icinga/icinga-notifications#406.