Closed s2156945 closed 1 year ago
Ah this is an important behaviour I’ve addressed but haven’t written about properly yet. They will render by changing the way the object(s) are selected. I’ve made notes that I’ll put here tomorrow.
I'm proposing to remove filter expressions from the interface, to instead be reference them by Service/Host group name.
I'll use the example elements from above. In the first element, this specified as the following expression:
"Audio Services ABC Ultimo" in service.groups && match("*mux1A", host.__name)
In the second element:
"site-abc-ultimo" in service.groups && "prj-dab" in host.groups
Those expressions don't have a name but you can sort of guess at what collection of objects the expression is selecting for. From the element's title; "Audio Services ABC Ultimo" in the first element and "ABC Ultimo" in the second.
Icinga provides an object type for this purpose: host and service groups.
The above expressions can be represented as a host/service group, specified by the same filter expression. For example:
apply ServiceGroup "abc-ultimo-mux1A" {
display_name = "ABC Ultimo Mux1A"
assign where "Audio Services ABC Ultimo" in service.groups && match("*mux1A", host.name)
}
I'd argue that giving a name to the group is clearer than using a raw expression.
Compare "men" to SELECT * WHERE gender="male"
.
Now that we've named the thing we were referring to all along, it can be queried from the API, Icingaweb, OpsGenie, notifications...
For Meerkat, you remove the freeform text field and the responsibilities of having such a feature re: documentation, error handling. Selecting a group is already done; you just click from a dropdown box.
I can imagine a use case where writing filter expressions and seeing some box change colour as a way to kind of evaluate the validity of an expression. For exploratory use cases, such as evaluating the results of some expressions, a basic command-line tool or minimal web app would have these bonuses over Meerkat:
I'm all for "little languages" AKA domain-specific languages. I would love to share how Unix and OpenBSD and Plan 9 all took advantage of them. And then there's those projects wrestling with ORMs over using plain SQL!
I think we can save a feature, dev budget, maintenance by sticking with only exposing the names of the groups - which themselves are defined using filter expressions.
Not implementing this feature means that groups will have to be made from the expressions specified in dashboards. From an overall operational viewpoint I anticipate a net-win since those groups can be used for notifications and in icingaweb dashboards They could even have a little documentation attached as a comment.
We discussed this and did an analysis of approx. 5000 elements which used a filter expression, rather than a name, to specify an icinga object. Approx. 50% can be replaced by a reference by name. But the other 50% would not be supported. So we worked out that we need to expose filter expressions in the UI.
One common use case is to create an element which represents the state of all services on a particular host. It's impractical to maintain ServiceGroups for each Host; there may be thousands to tens of thousands.
I’ve got this for line and svg icon elements. I haven’t figured out how it will work for card elements. Not yet sure how to represent all the attributes from each Icinga object.
For groups, we provide 2 attributes: the worst state and soonest check command of all objects in the group. We can just use all the same logic as it applies to a list of objects, which filter expressions return.
The ability to use the state attribute from one object (or objects), then render the text of an attribute from a different object would be covered by #148.
In that case I could submit the code I’ve got as is, close this issue, and leave the remaining to be done in #148
Describe the bug In V3 some elements do not show
Expected behavior elements are able to be ported from V2 JSON.
Screenshots
Example non-displaying SVG element config
Example non-displaying Card element