Project

General

Custom queries

Profile

Actions

Bug #20071

closed

Compliance incorrectly computed when two components have the same name and cfe vars are involved

Added by François ARMAND over 3 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
N/A
Category:
Web - Compliance & node report
Target version:
Severity:
Minor - inconvenience | misleading | easy workaround
UX impact:
User visibility:
Operational - other Techniques | Rudder settings | Plugins
Effort required:
Priority:
0
Name check:
To do
Fix check:
To do
Regression:
No

Description

This is related to #19990 but perhaps it's older than that.

In the case when we have two components with the same name, and at least one of them has a cfengine variable, and all returned report values could match the variable, we count all matching cases for the variable, not removing the value from the other component.
We know that with current structure, it's undecidable in general case (typically, if there is two cfengine vars that convert to a .* pattern), but here, we don't do the pairing that is tried in the old 6.2 cases (in recPairReports).

Example:

Expected reports: 
- block1: "componentXXX", expected value: "${loop}" 
- block2: "componentXXX", expected value: "inBlock2" 

Reports: 
- "componentXXX", "loop1", success
- "componentXXX", "loop2", success
- "componentXXX", "loop3", success
- "componentXXX", "inBlock2", error

In that case, componentXXX in block2 will have its correct value with status error.
But componentXXX in block1 will ALSO have status error with 4 reports, its own three loops and the one for blocks2.

Workaround

The workaround is easy: change the name for one of the component.

Correction

The only correct and definitive solution for that problem is to give each reprots an unique ID in expected reports and use that in compliance computation.


Related issues 5 (0 open5 closed)

Related to Rudder - Bug #19990: Technique editor blocks do not report as expectedReleasedFrançois ARMANDActions
Related to Rudder - Bug #22388: Bad report maching when reportid are presentReleasedVincent MEMBRÉActions
Related to Rudder - User story #20851: Regroup report with their values, not with the expanded valueReleasedFrançois ARMANDActions
Related to Rudder - Architecture #23084: Remove constraint on component name pattern for matching reportsReleasedVincent MEMBRÉActions
Related to Rudder - Bug #20808: Missing reports with a reportid are missing in complianceReleasedAlexis MoussetActions
#1

Updated by François ARMAND over 3 years ago

  • Related to Bug #19990: Technique editor blocks do not report as expected added
#2

Updated by Vincent MEMBRÉ about 3 years ago

  • Target version changed from 7.1.0~beta1 to 7.1.0~beta2
  • Priority changed from 16 to 30
#3

Updated by Vincent MEMBRÉ about 3 years ago

  • Target version changed from 7.1.0~beta2 to 7.1.0~rc1
#4

Updated by Alexis Mousset almost 3 years ago

  • Status changed from New to Rejected
#5

Updated by François ARMAND over 1 year ago

  • Related to Bug #22388: Bad report maching when reportid are present added
#6

Updated by François ARMAND over 1 year ago

  • Status changed from Rejected to In progress
  • Target version changed from 7.1.0~rc1 to 7.2.9
  • Priority changed from 30 to 0
  • Regression set to No
#7

Updated by François ARMAND over 1 year ago

  • Assignee set to François ARMAND
#8

Updated by François ARMAND over 1 year ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/4897
#9

Updated by François ARMAND over 1 year ago

  • Related to User story #20851: Regroup report with their values, not with the expanded value added
#10

Updated by François ARMAND over 1 year ago

  • Related to Architecture #23084: Remove constraint on component name pattern for matching reports added
#11

Updated by François ARMAND over 1 year ago

  • Related to Bug #20808: Missing reports with a reportid are missing in compliance added
#12

Updated by François ARMAND over 1 year ago

  • Status changed from Pending technical review to Resolved
Actions

Also available in: Atom PDF