Project

General

Profile

Actions

User story #5293

closed

Add a 'changes only' compliance mode, only reporting changes on systems

Added by François ARMAND over 9 years ago. Updated over 9 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Config management
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

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.


Subtasks 25 (0 open25 closed)

User story #5296: Create the logic to get execution reports for "error only" modeReleasedNicolas CHARLES2014-09-24Actions
User story #5568: Add migration script for new property "rudder.jdbc.maxPoolSize"RejectedFrançois ARMAND2014-09-24Actions
Bug #5658: full-compliance default value is wrongReleasedFrançois ARMAND2014-10-20Actions
Bug #5667: Bad logic in the computation of number of reportsReleasedNicolas CHARLES2014-10-21Actions
Bug #5710: Rudder 3.0 is missing migration elements (SQL script and property)ReleasedJonathan CLARKE2014-11-06Actions
Bug #5745: Rudder 3.0 configid migration uses the wrong conditionReleasedJonathan CLARKE2014-11-06Actions
User story #5294: Add a configuration option for the "error only" mode in admin tabReleasedFrançois ARMAND2014-09-05Actions
User story #5335: Set the value of the system variable RUDDER_REPORT_MODEReleasedFrançois ARMAND2014-09-05Actions
Bug #5494: Compilation error: missing modification in the PRReleasedFrançois ARMAND2014-09-05Actions
User story #5297: Adapt display to handle new compliance/change only modeReleased2014-07-22Actions
User story #5320: Update technique to understand "error only" modeReleasedNicolas CHARLES2014-07-24Actions
User story #5351: Create definition of system variable RUDDER_REPORT_MODE for reporting mode of RudderReleasedNicolas CHARLES2014-08-01Actions
User story #5434: Change the frequency of the agent executionReleasedNicolas CHARLESActions
User story #5473: Add node config id in StartRun/EndRun reports messageReleasedFrançois ARMAND2014-09-03Actions
User story #5501: Add Twitter boostrap CSS & JS in RudderReleasedVincent MEMBRÉ2014-09-08Actions
User story #5576: Add a heartbeat feature that force agent to periodically contact RudderReleased2014-09-26Actions
User story #5577: UI for configuring heartbeat by nodeReleasedFrançois ARMAND2014-09-26Actions
User story #5578: Heartbeat Rudder/technique integrationReleasedFrançois ARMAND2014-09-26Actions
User story #5579: Send reports from the agent to provide a heartbeatReleasedNicolas CHARLES2014-11-29Actions
Bug #5874: Start message from system techniques is sometimes not printed due to over-zealous lockingReleasedNicolas CHARLES2014-11-29Actions
Bug #5878: Apply fix from #5874 to ncf's copyReleasedNicolas CHARLES2014-11-29Actions
Bug #5883: Missing system variables for RUDDER_HEARTBEAT_INTERVAL and SEND_METRICS in TechniquesReleasedNicolas CHARLES2014-11-29Actions
Bug #5882: System variable RUDDER_REPORT_MODE is never setReleasedFrançois ARMAND2014-11-29Actions
Bug #5855: RUDDER_NODE_CONFIG_ID not in bundle common gReleasedJonathan CLARKE2014-11-28Actions
User story #5399: Create a system variable RUDDER_NODE_CONFIG_ID to store the node current configuration identifierReleasedNicolas CHARLES2014-08-18Actions

Related issues 1 (0 open1 closed)

Related to Rudder - Bug #5334: The archiving logic of execution reports needs to be adapted for "error only" report modeRejected2014-07-31Actions
Actions #1

Updated by François ARMAND over 9 years ago

  • Description updated (diff)
Actions #2

Updated by François ARMAND over 9 years ago

  • Project changed from 34 to Rudder
Actions #3

Updated by François ARMAND over 9 years ago

  • Status changed from 13 to Discussion
  • Assignee changed from François ARMAND to Jonathan CLARKE

I'm wondering if we should not have a 3 states mode:

- 1/ "compliance", corresponding to the actual mode: every reports is sent by the node for it's run, including START_RUN, SUCCESS, END_RUN. In that mode, we are able to check for nodes not responding and for the full execution of all rules components compared to the expected configuration (i.e, we are able to detect if actually 3 users where checked for, and not 2 or 4)

- 2/ "error only", where SUCCESS are not sent, but START_RUN/END_RUN are, and of course ERROR/REPAIRED are to. In that mode, we are also able to check if a node is not respondind, because even in full SUCCESS runs, we should have a START_RUN/END_RUN at the frequency of the agent. In that mode, we are not able to check if exactly all rules components are OK (missing results equals SUCCESS, and outnumbered result in SUCCESS won't be reported). This could be a good compromise for normal criticity infra, where full compliance is too ressources demanding.

- 3/ "silent" where ONLY ERROR/REPAIRED, and optionnally a HEARTBEAT reports are send. In that mode, when the run is all SUCCESS, NOTHING goes back to the server. So from the server, we can only update status when ERROR, REPAIRED or HEARTBEAT happen. That mode can be extremelly usefull for infrastructure where the network is limited and bandwith is a precisous ressource, or that the nodes are most of the time disconnected from networks (think embeded devices).

Actions #4

Updated by François ARMAND over 9 years ago

Well, thinking a little more about it, in fact the mode #2 is a subcase of the mode #3 for which the HEARTBEAT frequency is the same as the agen run freqency.

So we really have only two modes.

Actions #6

Updated by François ARMAND over 9 years ago

  • Subject changed from Create a "error only - disable compliance" mode to Rudder to Create a "changes only (disable compliance)" mode to Rudder
  • Description updated (diff)
Actions #7

Updated by Matthieu CERDA over 9 years ago

  • Target version changed from 140 to 3.0.0~beta1
Actions #8

Updated by Jonathan CLARKE over 9 years ago

  • Category set to Web - Config management
  • Status changed from Discussion to 12
Actions #9

Updated by Jonathan CLARKE over 9 years ago

  • Status changed from 12 to Pending release
Actions #10

Updated by Vincent MEMBRÉ over 9 years ago

  • Subject changed from Create a "changes only (disable compliance)" mode to Rudder to Add a 'changes only' compliance mode, only reporting changes on systems
Actions #11

Updated by Vincent MEMBRÉ over 9 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.0~beta1 which was release on 01/12/2014.

Actions

Also available in: Atom PDF