Project

General

Profile

Actions

Bug #9518

closed

When we just apply a configuration, reports is "missing" (not "pending")

Bug #9518: When we just apply a configuration, reports is "missing" (not "pending")

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

Status:
Released
Priority:
N/A
Category:
Web - Compliance & node report
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

When we just updated a configuration, we are getting a "missing" bar in place of a pending one.

Explain compliance for the node say:

[2016-10-24 14:45:41] TRACE explain_compliance.root - Run config for node root: UnexpectedUnknowVersion : nodeId exists in DB and has configId, expected configId is fc2e4563, but d59d725c was not found (node corruption?)
[2016-10-24 14:45:41] TRACE explain_compliance.root - Computing compliance for node root with: [UnexpectedUnknowVersion: expected NodeConfigId: fc2e4563/[2016-10-24T14:45:33.040Z-now] | last run: nodeConfigId: d59d725c received at 2016-10-24T14:40:54.000Z | expired at 2016-10-24T14:55:33.040Z]
[2016-10-24 14:45:41] WARN  explain_compliance.root - Received a run at 2016-10-24T14:40:54.000Z for node 'root' configId 'd59d725c' which is not known by Rudder, and that node should be sending reports for configId fc2e4563

But:

  • the run exists:

rudder=> select * from reportsexecution ;
 nodeid |          date          | complete | nodeconfigid | insertionid
--------+------------------------+----------+--------------+-------------
 root   | 2016-10-24 14:00:02+00 | t        | 0            |         102
 root   | 2016-10-24 14:00:03+00 | t        | 0            |         107
 root   | 2016-10-24 13:59:26+00 | f        |              |         131
 root   | 2016-10-24 14:05:44+00 | t        | b38a998d     |         132
 root   | 2016-10-24 14:10:50+00 | t        | b38a998d     |         177
 root   | 2016-10-24 14:15:50+00 | t        | b38a998d     |         213
 root   | 2016-10-24 14:20:50+00 | t        | b38a998d     |         249
 root   | 2016-10-24 14:25:51+00 | t        | 8bddfecb     |         285
 root   | 2016-10-24 14:30:52+00 | t        | 8bddfecb     |         321
 root   | 2016-10-24 14:35:53+00 | t        | bd1e3772     |         357
 root   | 2016-10-24 14:39:22+00 | t        | bd1e3772     |         394
 root   | 2016-10-24 14:40:54+00 | t        | d59d725c     |         430
 root   | 2016-10-24 14:45:56+00 | t        | fc2e4563     |         491
 root   | 2016-10-24 14:50:56+00 | t        | fc2e4563     |         526
 root   | 2016-10-24 14:55:56+00 | t        | fc2e4563     |         574
(15 rows)

The reported missing nodeConfidId is in nodeconfigurations table:

rudder=> select * from nodeconfigurations where nodeconfigid = 'd59d725c';

nodeid | nodeconfigid |         begindate          |          enddate           |                              configuration
--------+--------------+----------------------------+----------------------------+-------------------------------------------------------------------------
 root   | d59d725c     | 2016-10-24 14:39:41.589+00 | 2016-10-24 14:41:44.981+00 | {                                                                      +
        |              |                            |                            |   "modes":{                                                            +
        |              |                            |                            |     "globalPolicyMode":{                                               +
        |              |                            |                            |       "mode":"enforce",                                                +

And it is in nodes_info:

rudder=> select * from nodes_info;
-[ RECORD 1 ]------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
node_id    | root
config_ids | [
 {"2016-10-24T14:00:39.314Z":"b38a998d"}
,{"2016-10-24T14:22:14.536Z":"8bddfecb"}
,{"2016-10-24T14:32:59.197Z":"bd1e3772"}
,{"2016-10-24T14:39:41.589Z":"d59d725c"}
,{"2016-10-24T14:41:44.981Z":"97e1744"}
,{"2016-10-24T14:45:33.040Z":"fc2e4563"}
]

The nex run is correctly calculated:

[2016-10-24 14:46:03] TRACE explain_compliance.root - Run config for node root: ComputeCompliance : Last run at 2016-10-24T14:45:56.000Z is for the correct configId fc2e4563 and not expired, compute compliance
[2016-10-24 14:46:03] TRACE explain_compliance.root - Computing compliance for node root with: [ComputeCompliance: expected NodeConfigId: fc2e4563/[2016-10-24T14:45:33.040Z-now] | last run: nodeConfigId: fc2e4563 received at 2016-10-24T14:45:56.000Z | expired at 2016-10-24T14:55:56.000Z]
[2016-10-24 14:46:03] TRACE explain_compliance.root - Using merge/compare strategy between last reports from run at 2016-10-24T14:45:56.000Z and expect reports fc2e4563/[2016-10-24T14:45:33.040Z-now]
[2016-10-24 14:46:03] TRACE explain_compliance.root - Compute compliance for node root using: rules for which compliance is based on run reports: [32377fd7-02fd-43d0-aab7-28460a91347b->1][inventory-all->3][hasPolicyServer-root->3][root-DP->3][server-roles->3]; rule updated since run: []
[2016-10-24 14:46:34] INFO  com.normation.rudder.services.policies.DeployOnTechniqueCallback - Automatic batch update at 2016-10-24T14:46:33.606Z
[2016-10-24 14:51:03] TRACE explain_compliance.root - Run config for node root: ComputeCompliance : Last run at 2016-10-24T14:50:56.000Z is for the correct configId fc2e4563 and not expired, compute compliance
[2016-10-24 14:51:03] TRACE explain_compliance.root - Computing compliance for node root with: [ComputeCompliance: expected NodeConfigId: fc2e4563/[2016-10-24T14:45:33.040Z-now] | last run: nodeConfigId: fc2e4563 received at 2016-10-24T14:50:56.000Z | expired at 2016-10-24T15:00:56.000Z]
[2016-10-24 14:51:03] TRACE explain_compliance.root - Using merge/compare strategy between last reports from run at 2016-10-24T14:50:56.000Z and expect reports fc2e4563/[2016-10-24T14:45:33.040Z-now]
[2016-10-24 14:51:03] TRACE explain_compliance.root - Compute compliance for node root using: rules for which compliance is based on run reports: [hasPolicyServer-root->3][inventory-all->3][server-roles->3][root-DP->3][32377fd7-02fd-43d0-aab7-28460a91347b->1]; rule updated since run: []


Subtasks 1 (0 open1 closed)

Bug #9530: Each policy generation lead to a new nodeconnfigid even without promise writtenReleasedVincent MEMBRÉActions

Related issues 1 (1 open0 closed)

Related to Rudder - Bug #8761: New nodes have compliance warning for system technique just after being addedNewActions

Updated by François ARMAND over 9 years ago Actions #1

  • Description updated (diff)

Updated by François ARMAND over 9 years ago Actions #2

  • Description updated (diff)

Updated by François ARMAND over 9 years ago Actions #3

It may be a duplicate of (or related to) #8761

Updated by François ARMAND over 9 years ago Actions #4

  • Related to Bug #8761: New nodes have compliance warning for system technique just after being added added

Updated by François ARMAND over 9 years ago Actions #5

It is not a duplicate of #8761 because in the case of #8761, we actually have no expected configuration for the node in base. As soon as the generation is over, the node is reported in Pending, which is expected.

Updated by François ARMAND over 9 years ago Actions #6

So, it seems to happen for node root only, and it happens each time a new directive is added, for the time between the end of the generation where the directive is added to the first run reporting on the corresponding config id.

Updated by François ARMAND over 9 years ago Actions #7

  • 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/1335

Updated by François ARMAND over 9 years ago Actions #8

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

Updated by Alexis Mousset about 9 years ago Actions #9

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.0.0 which was released the 10th November 2016.

Actions

Also available in: PDF Atom