User story #5296
closed
User story #5293: Add a 'changes only' compliance mode, only reporting changes on systems
Create the logic to get execution reports for "error only" mode
Description
We need to build the logic that get execution reports and interprete them in the compliance disable / error only mode.
We must enforce that both compliance mode and non compliance mode have the same resulting datastructure and general service interfaces so that the display part can be build generallicaly.
The logic will use the user parameter of the compliance mode saved in our LDAP base.
It seems that a system variable with the value will have to be created to transmit the information to the node (so that they now if they should log or not).
Updated by François ARMAND over 11 years ago
- Project changed from 34 to Rudder
- Description updated (diff)
- Parent task deleted (
#5293)
Updated by François ARMAND over 11 years ago
- Parent task set to #5293
Updated by François ARMAND over 11 years ago
- Status changed from 8 to In progress
The general idea here is:
- we are using the table ReportsExecution to know, for each node, when was its last run (with actual reports reaching the server)
- we will only have such runs when a ERROR, REPAIRED (and latter HEARTBEAT) reports will be issued - that part is managed by thechniques loggging
- so for each node, we will be able to join with the executionReports table to find back the corresponding ERROR/REPAIRED reports
- we are also able to find back what was the expected reports at that time.
- from these data, for all node, we are able to construct back the state of all missing success
Updated by François ARMAND over 11 years ago
The work in progress on that is tracked in that branch: https://github.com/fanf/rudder/tree/ust_5293/dev_5296_add_error_only_report_mode
The main ideas are:
- we always think "by node" (i.e, for a rule, we get the nodes, and then we continue - possibly with some pruning)
- we have a "nodeConfigurationVersion", that is a hash of the node actuall configuration. It's store along with expected reports, and given in a system variable to be brought back in EndRun reports
- we must ensure a working system even when nodes don't have a nodeConfigurationVersion
Updated by François ARMAND about 11 years ago
- Pull Request set to https://github.com/Normation/rudder/pull/601
A PR is available here: https://github.com/Normation/rudder/pull/601
For now, it's mainly for review / curiosity.
The main code architecture and logic is in place. Tests covers the basis, more need to be added for non nominal paths and error management checking. And lot of cleaning remains to be done.
The UI MUST be adapted to match the new underlying logic, even the minimum to get something was done.
Updated by François ARMAND about 11 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from François ARMAND to Nicolas CHARLES
The PR is in an OK state, and can be reviewed.
The UI is in a "workable" state and will be enhance in #5297
Updated by François ARMAND about 11 years ago
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset 61826ff90cbe3f7a84c83fb43b17e8d4979a9c5b.
Updated by Matthieu CERDA about 11 years ago
- Target version changed from 140 to 3.0.0~beta1
Updated by Vincent MEMBRÉ almost 11 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.
- Announcement
- Changelog
- Download information: https://www.rudder-project.org/site/get-rudder/downloads/
Updated by Benoît PECCATTE over 10 years ago
- Tracker changed from Enhancement to User story