Fixes #23935: API for node group compliance #5272
Conversation
| val targetedNodeIds = targetedNodeIdsByRuleId(rule.id) | ||
| val isRuleTargetingGroup = | ||
| RuleTarget.merge(rule.targets).includes(GroupTarget(nodeGroup.id)) // targeted compliance | ||
| (isGlobalCompliance || isRuleTargetingGroup) && targetedNodeIds.exists(currentGroupNodeIds.contains(_)) |
There was a problem hiding this comment.
(:exploding_head:)
This adds the check for isRuleTargetingGroup only when compliance is not global (i.e. targeted compliance)
There are multiple of occurences of :
(condA || condB) && condC
in this PR and the way to read them is : "I always want to check condC", and "I only want to check condB when not condA"
|
PR updated with a new commit |
3 similar comments
|
PR updated with a new commit |
|
PR updated with a new commit |
|
PR updated with a new commit |
|
@clarktsiory Tests are not ok ! I wondering about the NoAnswer case. I need to look if this is the same behavior on nodes/rules/directives |
|
PR updated with a new commit |
clarktsiory
force-pushed
the
ust_23935/api_for_node_group_compliance
branch
from
c61cb57
to
26468b4
Compare
|
I rebased on master (some changes from the use of |
|
This PR is not mergeable to upper versions. |
|
OK, squash merging this PR |
VinceMacBuche
force-pushed
the
ust_23935/api_for_node_group_compliance
branch
from
26468b4
to
eea787d
Compare
https://issues.rudder.io/issues/23935
This adds two endpoints that return compliance computation by node group :
/compliance/groups/{id}for global compliance by taking into account any rule that apply to nodes within the group/compliance/groups/{id}/targetfor targeted compliance by taking into account only rules that target the group (using include/exclude targeting)In the yaml tests I used concrete examples (a simple one and a more complex one) and the result correspond to what is expected with a some caveats :
Setcollection. Maybe we should sort by 'compliance', from the "worst" ones to best ones ? Or by the name of the node/rule ? I left them as is so there is no specific orderNoAnswerreport type, which could be confusing (but may be better than omitting it completely). Later we could handle that case specifically to display which rule/directive have been overriden