Bug #6005
closedIf 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)
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 :/
Updated by Nicolas CHARLES almost 10 years ago
- Status changed from New to 8
- Assignee set to Nicolas CHARLES
- Priority changed from N/A to 1 (highest)
- node can change date
- server can change date
- date can change date
- 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 almost 10 years ago
- Status changed from 8 to Pending release
- % Done changed from 0 to 100
Applied in changeset 2025b631b7a73f88ec75b84cf911d9666c1cc3a7.
Updated by François ARMAND almost 10 years ago
Applied in changeset 7aad41361ec779169bc5288ab6d2023c7f7af32a.
Updated by Jonathan CLARKE almost 10 years ago
This ticket appears to be missing a PR.
Updated by Nicolas CHARLES almost 10 years ago
- Pull Request set to https://github.com/Normation/rudder/pull/727
Updated by Jonathan CLARKE almost 10 years ago
Thanks. I asked a question in the diff there, for ease of communication.
Updated by Vincent MEMBRÉ almost 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.
- Announcement 3.0
- Changelog 3.0
- Download information: https://www.rudder-project.org/site/get-rudder/downloads/
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