Bug #12060: Incomplete "Rules to be applied" summary when accepting a new nodes when using groups of groups - Rudder - Issue Tracker

Actions

Copy link

Bug #12060

closed

Incomplete "Rules to be applied" summary when accepting a new nodes when using groups of groups

Added by Nicolas CHARLES almost 7 years ago. Updated over 6 years ago.

Status:

Released

Priority:

N/A

Assignee:

Vincent MEMBRÉ

Category:

Web - Config management

Target version:

4.3.0~rc2

Pull Request:

https://github.com/Normation/rudder/p...

Severity:

Major - prevents use of part of Rudder | no simple workaround

UX impact:

User visibility:

Getting started - demo | first install | level 1 Techniques

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

Setup:
I defined a Group A, dynamic, with all nodes
I defined Group B, dynamic, that contains all nodes of group A
I defined a Rule Z, applied to group B

When I accept a node, I'd expect Rule Z to show up in the list of rules to be applied, but it ain't

Note: the same issue will happen with Nodecycle for rules on non-default lifecycle

Files

IMG_20180328_160533.jpg (498 KB) IMG_20180328_160533.jpg

François ARMAND, 2018-03-28 16:08

Related issues 2 (0 open — 2 closed)

Actions

Copy link

Updated by François ARMAND almost 7 years ago

Status changed from New to In progress
Assignee set to François ARMAND

Actions

Copy link

Updated by Vincent MEMBRÉ almost 7 years ago

Target version changed from 4.3.0~beta1 to 4.3.0~rc1

Actions

Copy link

Updated by Benoît PECCATTE almost 7 years ago

Severity set to Major - prevents use of part of Rudder | no simple workaround
User visibility set to Getting started - demo | first install | level 1 Techniques
Priority changed from 0 to 70

Actions

Copy link

Updated by Vincent MEMBRÉ over 6 years ago

Target version changed from 4.3.0~rc1 to 4.3.0~rc2
Priority changed from 70 to 69

Actions

Copy link

Updated by François ARMAND over 6 years ago

Translation missing: en.field_tag_list set to Blocking 4.3

Actions

Copy link

Updated by François ARMAND over 6 years ago

File IMG_20180328_160533.jpg IMG_20180328_160533.jpg added

So, this is how I think we can solve it.

We already have a function which, given a query, is able to tell which nodes match it.
Any dyngroup can be decompose in a simple, fully computable query and the dependance towards other groups, i.e towards other queries (and that, recursively).

The composition between the simple part and the group is either an AND (intersection of nodeids set) or an OR (union of nodeids).

So now, we can build a simple algo with 3 queues: TODO, BLOCKED, DONE. All dyn groups start in TODO. Then, we proceed the TODO queue iteratively. When a node has N dep (N > 0), it goes into BLOCKED.
Then, each time a group is fully computable (no dep), the set of nodeid matching it is evaluated, and it goes into DONE.
At that point, we put back each group in BLOCKED which were only blocked by the newly finished group at the end of TODO queue, and for each, we intersect or union the set of nodes matching.

We are sure to progress by at least one element in TODO (even when we put back some from BLOCKED, and BLOCKED never get refilled), so at some point TODO is empty. If some groups remain in BLOCKED, it means their dependencies can't be computed (mutual dependencies of dep towards static groups). We set these dependencies to nodeids == empty set, and we do the final TODO processing (after union/intersec).

And done!

An imagine to illustrate the process (it misses the last step where we zeroïze dependencies of group in the BLOCKED queue at the end)

Actions

Copy link