Project

General

Profile

Actions

Bug #9835

closed

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

Added by Nicolas CHARLES almost 8 years ago. Updated almost 8 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Compliance & node report
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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

Actions #1

Updated by Nicolas CHARLES almost 8 years 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

Actions #2

Updated by Nicolas CHARLES almost 8 years 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

Actions #3

Updated by Nicolas CHARLES almost 8 years ago

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

Updated by Nicolas CHARLES almost 8 years 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
Actions #5

Updated by Nicolas CHARLES almost 8 years ago

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

Updated by Vincent MEMBRÉ almost 8 years 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.

Actions

Also available in: Atom PDF