Project

General

Profile

Bug #9835

When we receive reports from node with old reports, caches are not used for compliance computation

Added by Nicolas CHARLES 11 months ago. Updated 9 months ago.

Status:
Released
Priority:
N/A
Category:
Web - Compliance & node report
Target version:
Target version (plugin):
Severity:
User visibility:
Effort required:
Priority:

Description

We have a cache for compliance computation in Rudder, to lower the stress on the database, and avoid computing again and again same compliance if it didn't change.
However, it is ignored (and recomputed!) for nodes that have outdated reports:
in checkAndUpdateCache we define a cache to be expired if the expirationDate of RuleNodeStatusReport is before now.

For nodes that send reports with old config id, we use UnexpectedVersion compliance, and its expirationDate is computed as currentConfigId.creation.plus(updateValidityDuration) in ExecutionBatch , so 5 minutes after a policy generation, it will always be in the past; so we'll keep hammering the database to get compliance info for these nodes

Associated revisions

Revision e3b70b4a
Added by Nicolas CHARLES 10 months ago

Fixes #9835: When we receive reports from node with old reports, caches are not used for compliance computation

History

#1 Updated by Nicolas CHARLES 11 months ago

The expirationTime should not be computed as this - it should either be "now + x minutes", or we should have a new field completely for cache
Note that when we receive new reports, the cache is updated by achedCompliance.invalidate (but the expirationTime is still in the past)

Francois, i'll need your input on this one, to validate that my diagnosis is correct, and suggested solution also

#2 Updated by Nicolas CHARLES 11 months ago

Ok, this is more complex than that:
I tried to replace expirationTime by val expirationTime = t.plus(updateValidityDuration)
but in this case, for the cache, I have expirationTime is "Some(2016-12-29T17:26:21.961+01:00,2016-12-29T18:16:21.000+01:00)" when a run with wrong report is received at 2016-12-29T18:11:21.000+01:00

First one is the expected one, second is the current one - but I don't know why we get both

#3 Updated by Nicolas CHARLES 10 months ago

  • Status changed from New to In progress
  • Assignee set to Nicolas CHARLES

#4 Updated by Nicolas CHARLES 10 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Nicolas CHARLES to François ARMAND
  • Pull Request set to https://github.com/Normation/rudder/pull/1429

#5 Updated by Nicolas CHARLES 10 months ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100

#6 Updated by Vincent MEMBRÉ 9 months ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.1.18, 3.2.11, 4.0.3 and 4.1.0~beta3 which were released today.

Also available in: Atom PDF