Rudder

In the past, we choose to not rely on node date/time to decide what was the "last" run because they were too easy to mismanage and lead to bug like #6005 (a node with time in the futur, then time is corrected will have an incorrect status for as long as what was futur date is reached).

This problem didn't disapeared, so I don't know how to handle that correctly.

Some more details: today, we take compliance based on the last full run received on rudder, with last defined as "last inserted":

https://github.com/Normation/rudder/blob/branches/rudder/6.1/webapp/sources/rudder/rudder-core/src/main/scala/com/normation/rudder/reports/execution/ReportsExecutionRepository.scala#L64

  /**
   * Find the last execution of nodes, whatever is its state.
   * Last execution is defined as "the last executions that have been inserted in the database",
   * and do not rely on date (which can change too often)
   * The goal is to have reporting that does not depend on time, as node may have time in the future, or
   * past, or even change during their lifetime
   * So the last run are the last run inserted in the reports database
   * See ticket http://www.rudder-project.org/redmine/issues/6005
   */

To change that core hypothesis on report processing, we need to consider the following cases (because time in distributed environement is complicated and clock are famously reliables):

- what happen when rudder server|relayd|node is in the future? In the past? Future then past? Past then future?
- how do we prevent a broken state to remains broken when new reports come?
- how to we compute "a reasonnable delay since we updated policy to get a response from node" when relayd can send historical reports ?

It seems that at least part of the answer is to:

- forbid reports in the future compared to rudder server (even if it breaks when it's rudder which is in the past, at least it get corrected once rudder is again correctly configured),
- still keep insertion time to be able to say "whatever the reports date, I know that that report is older than some reasonnable amount of time, I should have received a new one"
- find a definition of "last" (don't forget there was problems linked to the fact that there were a differences between start run / reports time / end run, and that there were cases where two runs were mixed up - even if that case should not happen anymore with relayd and full run sent).

Of course we won't have correct answers in all cases, especially when part of the system is in defect (bad clock). But we need to have a clear answer for all cases.

Also, for sending old report to have any usefulness, we need to be able to compute compliance for arbitrary dates in the past. That means that:

- we need to keep enought expected reports in the past,
- we need to be able to do the computation, which is not possible now (because it highly depends of the relative date of "last generation end" compared to "run received")
- we need to actually do something with these raports: process compliance, save it, do something with it. Today, nothing it done in that regard.

So for now, the best solution is perhaps to just disable sending old reports on relayd.