Bug #9835: When we receive reports from node with old reports, caches are not used for compliance computation - Rudder - Issue Tracker

Actions

Copy link

Bug #9835

closed

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

Added by Nicolas CHARLES over 7 years ago. Updated about 7 years ago.

Status:

Released

Priority:

N/A

Assignee:

François ARMAND

Category:

Web - Compliance & node report

Target version:

3.1.18

Pull Request:

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

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

Copy link

Updated by Nicolas CHARLES over 7 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

Copy link

Updated by Nicolas CHARLES over 7 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

Copy link