Bug #5329: False "no answer" reporting when rules with "unique" directive are overridden - Rudder - Issue Tracker

Actions

Copy link

Bug #5329

closed

User story #5899: Do not display reporting on overriden 'unique' Directives

False "no answer" reporting when rules with "unique" directive are overridden

Added by Lionel Le Folgoc over 10 years ago. Updated about 10 years ago.

Status:

Released

Priority:

N/A

Assignee:

Nicolas CHARLES

Category:

Target version:

3.0.0~beta1

Pull Request:

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

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

Hi,

Let's consider a single, non multi-instanciable technique, to set the console keyboard layout (KEYMAP=xy in /etc/vconsole.conf).
Create two directives from this technique, one to set a US layout, the second on to set a Bosnian layout (see attached picture). They are supposed to be applied to different groups, of course. But, if the associated rules target by mistake an intersecting group of nodes (e.g. a node is in both groups), the global report for these nodes become non-informative.

When two rules (from the same non multi-instantiable technique) are applied to the same node, the rule with the lowest priority will not be generated for the node, and so will be stuck as "Applying"/"No report" in reporting. And this is the "worst result", so the global reporting for this node will show up as "No report", even if everything else worked.

Wouldn't it be possible to create an "Overridden" status for that, which doesn't count in the global status, but can be useful for the admin to detect any unwanted conflict?

Thanks.

Files

screenshot-20140730180826.png (11.4 KB) screenshot-20140730180826.png

Lionel Le Folgoc, 2014-07-31 09:31

Related issues 4 (0 open — 4 closed)

Actions

Copy link

Updated by François ARMAND over 10 years ago

hello Lionel,

Thanks for reporting. It seems to be a duplicate of #1186 (a really old one). Does I get correctly your problem?
If so, it seems that the "mission criticality" of that bug was underestimated, and we should change it's priority.

Actions

Copy link

Updated by François ARMAND over 10 years ago

Moreover, I thing that you idea of an "overrideen" status is quite good and allows the user to see what choice was made.

Actions

Copy link

Updated by François ARMAND over 10 years ago

Status changed from New to Discussion
Assignee set to François ARMAND

Actions

Copy link

Updated by Lionel Le Folgoc over 10 years ago

Indeed, it is identical.
+1 to bump it to "more important". ;-)
Thanks.

Actions

Copy link

Updated by François ARMAND over 10 years ago

Assignee changed from François ARMAND to Jonathan CLARKE

Assiging to Jon to get some feedback from him.

Actions

Copy link

Updated by François ARMAND over 10 years ago

Subject changed from More precise reporting when rules are overridden? to False "no answer" reporting when rules with "unique" directive are overridden

Actions

Copy link

Updated by François ARMAND over 10 years ago

Status changed from Discussion to Rejected

~~Duplicated by #5329~~

Actions

Copy link

Updated by François ARMAND over 10 years ago

Status changed from Rejected to In progress
Assignee changed from Jonathan CLARKE to François ARMAND

Sorry, bad bug closed! We keep that one, as the example is pretty good and clearly depicted the importance of the correction.

Actions

Copy link

Updated by François ARMAND over 10 years ago

I'm giving that one a look when working on reporting.

I think we can handle it in three ways:

- 1/ don't write that we expect reports for that node, for that directive. The corresponding overriden directive won't appear anymore in reports information.
- 2/ write that expected reports for that node is actually not expected. We can translate that in reports information with a special "overriden" status
- 3/ write that expected reports for that node is overriden by that other directive. We can translate that in the reports information with a special status "overriden by that directive".

It seems that from an user point of view, 3 > 2 > 1. Of course, the dev time is in the exact other way :)

To be faire: 1 and 2 should compare in complexity given our backend structure. And 3 may be not that much more difficult. Moire information to come !

Actions

Copy link

#10

Updated by Jonathan CLARKE about 10 years ago

Target version set to 140

Actions

Copy link

#11

Updated by François ARMAND about 10 years ago

Pull Request set to https://github.com/Normation/rudder/pull/645

Work in Progress: https://github.com/Normation/rudder/pull/645

Actions

Copy link

#12

Updated by François ARMAND about 10 years ago

Assignee changed from François ARMAND to Nicolas CHARLES

Nico, I set you for that one because it's likelly I won't be able to finish it.

For now, the logic to propagate what directive is overiden on which node to the update of expected reports is here. So it remains to do either 1/ or 3/ (2 is silly, has we have the information in base, it is not more difficult to write the CF3DraftId than a boolean).

So, if 1/ is chosen, the "update expected reports" logic must be updated to filter out directive for rule/node that are overriden.
If 3/ is chosen, in place of filtering out like in 1/ we need to add the relevant information in database ( expectedReportsNodes table is already updated with a "overriden" field - perhaps overriden_by would be better), and then use it when merging expected and received reports, at least managing case where we get a reports that should have been overriden (=> unexpected) and when we actually don't get a report (==> not applicable, or - not sure if necessary - a new Status, "overriden". But I don't see the point, it is really not applicable, and we can forge a message "that component is overiden by an other directive blablable).

Actions

Copy link

#13