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)

Added by Nicolas CHARLES about 10 years ago. Updated about 10 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 CLARKE2014-12-17Actions
Bug #6025: Typo in migration filename in .spec fileReleasedNicolas CHARLES2014-12-17Actions
Bug #6013: Typo in the migration script for insertionid in reportsexecutionReleasedVincent MEMBRÉ2014-12-16Actions

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 ARMAND2014-12-22Actions
Related to Rudder - Architecture #17180: Compliance incorrectly computed with old reports or runs not sent in node chronological orderNewFrançois ARMANDActions
Actions #1

Updated by Nicolas CHARLES about 10 years ago

  • 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

Actions #2

Updated by Nicolas CHARLES about 10 years ago

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

Updated by Jonathan CLARKE about 10 years ago

This ticket appears to be missing a PR.

Actions #5

Updated by Nicolas CHARLES about 10 years ago

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

Updated by Jonathan CLARKE about 10 years ago

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

Actions #7

Updated by Vincent MEMBRÉ about 10 years ago

  • Status changed from Pending release to Released

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

Actions #8

Updated by François ARMAND over 4 years ago

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

Also available in: Atom PDF