Project

General

Profile

Actions
Copy link

Bug #8051

closed

Compliance is not correctly computed if we receive run agent right after generation

Bug #8051: Compliance is not correctly computed if we receive run agent right after generation

Added by Nicolas CHARLES over 10 years ago. Updated about 10 years ago.

Status:
Released
Priority:
1 (highest)
Assignee:
Nicolas CHARLES
Category:
Web - Compliance & node report
Target version:
3.0.16
Pull Request:
https://github.com/Normation/rudder/p...
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

I generated promises, and run agent right away after that
The sent reports are correct
reportsexecution:

 root   | 2016-03-08 20:51:52+00 | t        | 955012795    |         747
 root   | 2016-03-08 20:52:20+00 | t        | -2036910663  |         790

reports do show up in technical logs
nodes_infos is

 root    | {"-2036910663":"2016-03-08T20:52:16.474Z","-1439985566":"2016-03-08T20:41:40.652Z","963405331":"2016-03-08T20:28:31.928Z","-1553294083":"2016-03-08T20:41:21.995Z","955012795":"2016-03-08T20:41:49.768Z","801954688":"2016-03-08T20:27:15.608Z","1904794682":"2016-03-08T20:11:23.712Z","-1729685780":"2016-03-08T20:39:54.108Z"}

but the explain compliance logger tells me:

[2016-03-08 20:52:24] TRACE explain_compliance.root - Computing compliance for node root with: [Pending: until 2016-03-08T21:02:1
6.474Z expected NodeConfigId: -2036910663/[2016-03-08T20:52:16.474Z-now] | last run: nodeConfigId: 955012795/[2016-03-08T20:41:49.768Z-2016-03-08T20:52:16.474Z] received at 2016-03-08T20:51:52.000Z]
[2016-03-08 20:52:24] TRACE explain_compliance.root - Node is Pending with reports from previous run, using merge/compare strategy between last reports from run 955012795/[2016-03-08T20:41:49.768Z-2016-03-08T20:52:16.474Z] and expect reports -2036910663/[2016-03-08T20:52:16.474Z-now]
[2016-03-08 20:52:24] TRACE explain_compliance.root - Compute compliance for node root using: rules for which compliance is based on run reports: [server-roles->2][inventory-all->2][root-DP->2][hasPolicyServer-root->2]; rule updated since run: [32377fd7-02fd-43d0-aab7-28460a91347b->6]

It is as if it didn't see the 20:52:20 run

After next run, it does tell me

[2016-03-08 20:55:34] TRACE explain_compliance.root - Computing compliance for node root with: [CheckChanges: expected NodeConfigId: -2036910663/[2016-03-08T20:52:16.474Z-now] | last run: nodeConfigId: -2036910663/[2016-03-08T20:52:16.474Z-now] received at 2016-03-08T20:52:20.000Z | expire at 2016-03-08T21:02:20.000Z]
[2016-03-08 20:55:34] TRACE explain_compliance.root - Using merge/compare strategy between last reports from run -2036910663/[2016-03-08T20:52:16.474Z-now] and expect reports -2036910663/[2016-03-08T20:52:16.474Z-now]

it seems as if reports used are of by one

Subtasks 3 (0 open — 3 closed)

Bug #8344: Missing relevant information about why the compliance is what it is on nodeReleasedNicolas CHARLESActions
Bug #8363: Some agent runs are not seen in the update processRejectedNicolas CHARLESActions
Bug #8364: Only invalidate cache for node with new completed runsReleasedNicolas CHARLESActions

Related issues 5 (0 open — 5 closed)

Related to Rudder - Bug #7743: Compliance take into account expired runReleasedNicolas CHARLESActions
Related to Rudder - Bug #8118: When a node send reports with a wrong config_id it is never marked as unresponsiveReleasedNicolas CHARLESActions
Related to Rudder - Question #8176: All nodes compliance report unexpected/missing except root server.ResolvedActions
Related to Rudder - Bug #8424: When updating runs, hooks should really be asyncReleasedBenoît PECCATTEActions
Has duplicate Rudder - Bug #8337: Broken compliance summary on a nodeRejectedActions

Updated by Nicolas CHARLES over 10 years ago Actions
Copy link
 #1

  • Related to Bug #7743: Compliance take into account expired run added

Updated by Nicolas CHARLES over 10 years ago Actions
Copy link
 #2

  • Related to Bug #7336: Node stuck in "Applying" status added

Updated by Nicolas CHARLES over 10 years ago Actions
Copy link
 #3

ok, this is not happening always, and hard to reproduce.

Updated by Vincent MEMBRÉ over 10 years ago Actions
Copy link
 #4

  • Target version changed from 3.0.15 to 3.0.16

Updated by Alexis Mousset about 10 years ago Actions
Copy link
 #5

I'm seeing a similar issue: After each generation, I see some missing reporting (between 5 and 100% missing) on some nodes (between 5 or ten over around 50). I cannot identify any pattern in the missing reports.

Updated by Jonathan CLARKE about 10 years ago Actions
Copy link
 #6

  • Translation missing: en.field_tag_list set to Next minor release

Updated by François ARMAND about 10 years ago Actions
Copy link
 #7

  • Status changed from New to In progress

Updated by François ARMAND about 10 years ago Actions
Copy link
 #8

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/rudder/pull/1099

Updated by François ARMAND about 10 years ago Actions
Copy link
 #9

  • Related to Bug #8118: When a node send reports with a wrong config_id it is never marked as unresponsive added

Updated by François ARMAND about 10 years ago Actions
Copy link
 #10

  • Related to Question #8176: All nodes compliance report unexpected/missing except root server. added

Updated by François ARMAND about 10 years ago Actions
Copy link
 #11

So it seems that somehow, the calls to future { } lead to some king of deadlock, and the corresponding code was never executed. It may be linked to the fact that there was a future{} in an method called from a future{}, or not.

At least, removing the future and making the order of execution stricter lead to a comprehensive behavior from the user. If the last run in "select * from reportsexecution order by date desc limit 5;" is marked as finished, just after - and BEFORE the next processing of runs - the compliance is reprocessed, and the debug output of 

<logger name="com.normation.rudder.services.reports.CachedReportingServiceImpl" level="debug" />
and

<logger name="explain_compliance.root" level="trace" additivity="false">
    <appender-ref ref="OPSLOG" />
    <appender-ref ref="STDOUT" />
  </logger>

are consitant.

Updated by Jonathan CLARKE about 10 years ago Actions
Copy link
 #12

  • Related to deleted (Bug #7336: Node stuck in "Applying" status)

Updated by François ARMAND about 10 years ago Actions
Copy link
 #13

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100

Updated by François ARMAND about 10 years ago Actions
Copy link
 #14

  • Related to Bug #8424: When updating runs, hooks should really be async added

Updated by François ARMAND about 10 years ago Actions
Copy link
 #15

  • Related to Bug #8337: Broken compliance summary on a node added

Updated by François ARMAND about 10 years ago Actions
Copy link
 #16

  • Related to deleted (Bug #8337: Broken compliance summary on a node)

Updated by François ARMAND about 10 years ago Actions
Copy link
 #17

  • Has duplicate Bug #8337: Broken compliance summary on a node added

Updated by Vincent MEMBRÉ about 10 years ago Actions
Copy link
 #18

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.16, 3.1.10 and 3.2.3 which were released on 2016-06-01, but not announced.

Actions
Copy link

Also available in: PDF Atom