Project

General

Profile

Actions

Bug #6005

closed

If a node had a date in the future, but returned to current time, the reporting will always be invalid (until it catches up with the future date)

Bug #6005: If a node had a date in the future, but returned to current time, the reporting will always be invalid (until it catches up with the future date)

Added by Nicolas CHARLES about 11 years ago. Updated about 11 years ago.

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

Description

If i set the date of a node in the future, then restore it to current time, it will always have no report/unexepected reports until it catches up with the future date

The issue is that we look for the last (in term of date) execution date of this node, in the reportsexecution table, which can be in a distant future if there were desynchronisation

There is no simple solution:
  • we can take the last reports before current time (will fail if the node is consistently desynchronized, the behaviour of that exists in 2.11 and before)
  • we can modify the table reportsexecution to add when we added the entry in the table (but it is not perfect, as we can have reports arriving out of order given the nature of syslog), and we are dealing with them asynchronously

First solution is easiest to implement, second is a bit more tricky, but none of them are perfect :/


Subtasks 3 (0 open3 closed)

Bug #6011: Execute the migration script for the change of table reports executionReleasedJonathan CLARKEActions
Bug #6025: Typo in migration filename in .spec fileReleasedNicolas CHARLESActions
Bug #6013: Typo in the migration script for insertionid in reportsexecutionReleasedVincent MEMBRÉActions

Related issues 2 (1 open1 closed)

Related to Rudder - Bug #6038: Wrong reporting after execution of migration script to change the way reports are used from the databaseReleasedFrançois ARMANDActions
Related to Rudder - Architecture #17180: Compliance incorrectly computed with old reports or runs not sent in node chronological orderNewFrançois ARMANDActions

Updated by Nicolas CHARLES about 11 years ago Actions #1

  • Status changed from New to 8
  • Assignee set to Nicolas CHARLES
  • Priority changed from N/A to 1 (highest)
Ok, date are really not reliable:
  1. node can change date
  2. server can change date
  3. date can change date
so we'll use the following principle:
  • when we extract the list of reports received, we take the timestamp, node id, and also first id of insertion in the report table (this number is strictly increasing)
  • when we looks for reports, we don't search anymore the last by date, but the last by this id

We'll need to update the table reportsexecution to add the id (which is not an id at all), update the queries on it, and of course make a migration script. This migration script must fetch for each of the last run (by date) the id in the reports tables

Updated by Nicolas CHARLES about 11 years ago Actions #2

  • Status changed from 8 to Pending release
  • % Done changed from 0 to 100

Updated by Jonathan CLARKE about 11 years ago Actions #4

This ticket appears to be missing a PR.

Updated by Nicolas CHARLES about 11 years ago Actions #5

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

Updated by Jonathan CLARKE about 11 years ago Actions #6

Thanks. I asked a question in the diff there, for ease of communication.

Updated by Vincent MEMBRÉ about 11 years ago Actions #7

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.0~beta2, which were these days.

Updated by François ARMAND almost 6 years ago Actions #8

  • Related to Architecture #17180: Compliance incorrectly computed with old reports or runs not sent in node chronological order added
Actions

Also available in: PDF Atom