2011/5/3 Grégory Starck <g.starck@...>
> I'm seeing the exact same semantic for the "," separator you know ;)
> hostgroup_name A , B
> where A and B are valid groups name (but could be hostgroup_name
> subexpressions (same parsing rules so)) and designate each one a specific
> set of host members (some hosts can be part of both sets).
> will result/be translated in a "A | B" "set" result where "A" and "B" are
> so basic sets and where "|" is the basic "OR" operator that can be applied
> on such sets. That's why I said that the "|" and "," chars have the same
> meaning if used in a hostgroup_name expression. but effectively, because
> it's the one of nagios, "," should be kept as the primary default one.
> though we can still handle boths.. (though I agree it should be better to
> only consider one).
> admin must know what he does, or he must at least be able to understand it
> by working on it - otherwise it's not an admin :p
I think there are quite a lof of admins that got too much workload for
having the time to read the whole doc, and so features should be quite
explicit if possible. Of course there are things that can't be direct (if
the admin don't read why passive poller is good for DMZ, we can't help him
:) ), but if we can, should be as simple as possible :)
I think we *have* to handle the case "A ! B". and also, imho, the case "A &
> ( ! B )" is syntactically invalid, or at least quite weird .. effectively.
> It can be, imho more correctly, written like "A , ! B " : "the hosts
> that are in A but not in group B (if there are some)".
> if you would want something more "complex" (I like complexity :p),
> hostgroup_name A, ! B , C , ! D
> then the hosts corresponding to this expression is straight when translated
> as a "set" expression :
> ==> the hosts that are in : (A + C) - (B + D)
> (the rule when a subexpression, part of an higher expression (whose
> subexpressions are "," separated), begins with "!" is so:
> takes all the subexpressions that are not negated with the "!", then "add"
> them together and keep the result in variable1, then take all the
> subexpressions that are negated and add them together and keep the result in
> variable2. Then do "variable1 - variable2" where both variables are set
> object. )
Oh, it's true that in all others places of the configuration, A, !B mean A
but NOT B, and it's not what I was thinking with the hostgroups expressions
(more like A and all elements but not the one in B). I was wrong. Your
version is far more logical when we look at the whole configuration habits
:) (and more easy to use for exclusions :p ). More logical + more simple ->
go for it :)
> it's effectively absolutely not trivial hostgroup_name expressions of a
> service definition but they definitively need to be correctly handled :p