Rudder

Today, Rudder only support one reporting mode which is a compliance assessing mode.
That means that at any time, Rudder knows what execution report each node should have send, compare it to what the node actually sent, and based on that display what is ok and what is wrong.

To be more precise, when a node run the agent, it execute compliance assessment on a list of rules, composed of several directives, composed of several components, composer of several values, possibly avaiting several message (execution reports).

Compliance assessment on each component produces reports among success (yes !), error ("the component is not in the correct state and I can't change that"), "repaired" (the componenent was not on the correct state and I corrected it to the correct one), and other status failing in either of this 3 kinds or not relevant for compliance (log/info messages).

In compliance checking mode (the current, only mode available), Rudder will look if the node exactly sent the correct number of messages throught execution reports, even if they are ALL success, because getting 0 or more than two success when exactly one isexpected is an error, and getting "success" for unknow components is clearly spurious and need investigation.

That mode is great but generate a lot of traffic on the wire. So sometime, we could afford, even prefer, a mode where only changesù ("error" and "repaired" status) are sent back to the server. In that mode, we assume that the absence of error is a success, and so that account for the "compliance disabled" semantic. In that mode, we will not be able to detect compliance drift like on the compliance one above, but on the other hand it will be far less chatty.

From a more technical point of view, even in changes-only mode, we will keep the system logs "agent run start / agent run end" that a node send to indicate that the agent runs during that period if other changes have to be notified to the server. We will consider that any reports not sent by the node in that interval are actually success reports.

Moreover, some "agent run start / agent run end" may not be send to the server because no changes happened in that run. In that case, periocically, even if everything is ok, a heartbeat message can be send (surrounded by run start/run end), so that the server knows that the node is alive and actually check things.