Bug #19740
closed
When 2 changes are close in time, expected report on the compliance page don't show the new config
Added by Nicolas CHARLES about 3 years ago.
Updated almost 3 years ago.
Category:
Web - Compliance & node report
Description
it correctly showed that the config was recent, but didn't show the new directive. Running the agent solved the issue
Root cause analysis for latter reference: we need to ensure that when new expected reports are saved, then there is a compliance computation done for them. Here, we had both in parallele (the time taken to reach "new expect report available in base" was longer than the one to trigger and compute compliance, at least to reach the point where compliance get expected reports).
Since we now cache that info, the info was wrong until next compliance computation (that's was running agent on node solved the problem).
- Target version changed from 7.0.0~beta1 to 900
- Target version changed from 900 to 7.0.0~beta2
- Subject changed from when polcy generation failed, and then worked again after fixing the technique, the expected report on the compliance page didn't show the new config to When 2 changes are close in time, expected report on the compliance page don't show the new config
it tells me
This node has recently been assigned a new policy but no reports have been received for the new policy yet.
This is expected, the node is reporting on the previous configuration policy and should report on the new one at latest 2021-09-08 13:10:20+0000. Previous known states are displayed below. The latest reports received for this node are from a run started at 2021-09-08 13:00:20+0000 with configuration ID 20210908-083851-64212646.
Current configuration ID for this node is '20210908-130242-4ff5f559' (generated on 2021-09-08 13:02:42+0000).
while database says it's 20210908-130332-3efeda1f
it seems the expected reports cache is not correcly updated
and nothing enforces that there aren't any pending expectedreport changes before recomputing compliance
two issues: an init after every update of nodeconfigurationservice
and we need to have the nodeconfigurationservice trigger the compliance somehow (without failing)
- Status changed from New to In progress
- Assignee set to Nicolas CHARLES
- Status changed from In progress to Pending technical review
- Assignee changed from Nicolas CHARLES to François ARMAND
- Pull Request set to https://github.com/Normation/rudder/pull/3876
- Description updated (diff)
- Status changed from Pending technical review to Pending release
- Status changed from Pending release to Released
This bug has been fixed in Rudder 7.0.0~beta2 which was released today.
Also available in: Atom
PDF