Bug #2755: The server node doesn't seems to send some reports: common/update, common/log system for reports distributePolicy - Rudder - Issue Tracker

Custom queries

8.1 beta
Bugs triage
My TR
Need technical review
Open bugs (all)
Open bugs (UI - UX)
Open issues 8.0
Open UX defects (all)
Opened by users

Actions

Copy link

Bug #2755

closed

The server node doesn't seems to send some reports: common/update, common/log system for reports distributePolicy

Added by Nicolas PERRON over 11 years ago. Updated over 11 years ago.

Status:

Released

Priority:

Assignee:

Nicolas PERRON

Category:

System techniques

Target version:

2.4.0~beta4

Pull Request:

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

Somes reports are in a "No answer" state : common/update, common/log system for reports distributePolicy

If I try to force an update, no report is sent:

root@server-1:~# /opt/rudder/sbin/cf-agent -KI -b update
 !! Duplicate selection of value for variable "execRun" in scope g
 !! Rule from /var/rudder/cfengine-community/inputs/common/1.0/site.cf at/before line 58
 !! Duplicate selection of value for variable "execRun" in scope g
 !! Rule from /var/rudder/cfengine-community/inputs/common/1.0/site.cf at/before line 58
 !! Duplicate selection of value for variable "execRun" in scope g
 !! Rule from /var/rudder/cfengine-community/inputs/common/1.0/site.cf at/before line 58
 !! Duplicate selection of value for variable "execRun" in scope g
 !! Rule from /var/rudder/cfengine-community/inputs/common/1.0/site.cf at/before line 58
 >> Using command line specified bundlesequence
root@server-1:~#

Files

noResponsesReports.png (63.2 KB) noResponsesReports.png

Nicolas PERRON, 2012-08-02 10:56

Related issues 2 (0 open — 2 closed)

	Related to Rudder - User story #1971: Impossible to manage rudder server via web interface	Released	Nicolas PERRON	2012-07-21	2012-07-21		Actions
	Related to Rudder - Bug #6648: "Update" component of common technique sometimes return unexpected status and has incomplete reporting	Released	Benoît PECCATTE	2015-05-21			Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

Status changed from New to In progress
% Done changed from 0 to 90

All reports from the server are now made but it still an issue on distributePolicy part.
Now, the status of the distributePolicy is "Unkown", probably because of the number of reports returned which could be superior to number of expected reports.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

Target version changed from 2.4.0~beta3 to 2.4.0~beta4

This is not a blocking issue so I moved it to the next run.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

Nicolas PERRON wrote:

This is not a blocking issue so I moved it to the next run.

But we still need a technical review for the commits in 2.4.0~beta3

Actions

Copy link

Updated by Matthieu CERDA over 11 years ago

This looks OK. For the next part, we should:

Take a look at the metadata.xml, to see which reports are expected
Take a look at the expectedReports table in the Rudder server SQL rudder database.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

The problem has not been fixed so we still need work on it. Technical review can't be considered as done.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

It seems that no reports are expected for the distributePolicy promises:

rudder=# 
rudder=# SELECT * FROM expectedreports WHERE ruleid='root-DP';
 pkid | nodejoinkey | ruleid  | serial |      directiveid      |    component     | cardinality | componentsvalues |         begindate          |          enddate           
------+-------------+---------+--------+-----------------------+------------------+-------------+------------------+----------------------------+----------------------------
    1 |           1 | root-DP |      1 | root-distributePolicy | distributePolicy |           0 | []               | 2011-11-02 13:37:31.692+01 | 2012-02-13 10:47:07.677+01
   29 |          19 | root-DP |      2 | root-distributePolicy | distributePolicy |           0 | []               | 2012-02-13 10:47:07.683+01 | 2012-02-13 11:22:34.762+01
   34 |          21 | root-DP |      3 | root-distributePolicy | distributePolicy |           0 | []               | 2012-02-13 11:22:34.771+01 | 2012-08-16 14:44:31.723+02
   44 |          26 | root-DP |      4 | root-distributePolicy | distributePolicy |           0 | []               | 2012-08-16 14:44:31.805+02 |

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

It seems that it is related to a Webapp bug: #2817

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

This issue is not as trivial as expected.
The distributePolicy promises has been coded to be DRY in code execution but not for reporting.

Example:
aliveCheck.st permit to check is Rudder and Endpoint applications are up.
They are not using other component for reporting than "distributePolicy", like most of the other distributePolicy promises.

"@@DistributePolicy@@result_success@@&TRACKINGKEY&@@distributePolicy@@None@@$(g.execRun)##$(g.uuid)@#The $(site_to_check) web application is running"

In the metadata.xml, to catch each of these actions ( check rudder and endpoint), we need two components.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

I'm not sure about all of this.
The goal is to be able to have reports from a policy server which are enhancement for Rudder 2.4. Nevertheless, Policy Templates/Techniques modifications can be made on branch 2.3 and 2.4. Then, what about this issue ?

Should we commit modifications on branch 2.3 (which include reverting previous commit on this ticket) knowing that the results will be displayed only on a Rudder 2.4 server ? or should we commit all modifications on branch 2.4 ?

Actions

Copy link

#10

Updated by Nicolas PERRON over 11 years ago

% Done changed from 90 to 50

The work on this ticket is far from being done.

Actions

Copy link

#11

Updated by Nicolas PERRON over 11 years ago

Status changed from In progress to Pending technical review
% Done changed from 50 to 100

Applied in changeset commit:06e2da401f48b79acbc25e4f8166aeb457a187d1.

Actions

Copy link

#12

Updated by Nicolas CHARLES over 11 years ago

Status changed from Pending technical review to In progress
% Done changed from 100 to 80

Nicolas, I find these reports very dubious in propagatepromises.st

        (tools_propagated|tools_propagated.promises_propagated.masterfiles_propagated.license_copied).!(could_not_propagate_tools|could_not_propagate_promise|could_not_propagate_masterfiles|could_not_copy_license)::
            "@@DistributePolicy@@result_success@@&TRACKINGKEY&@@Propagate promises@@None@@$(g.execRun)##$(g.uuid)@#All files have been propagated";
        !((tools_propagated|tools_propagated.promises_propagated.masterfiles_propagated.license_copied).(could_not_propagate_tools|could_not_propagate_promise|could_not_propagate_masterfiles|could_not_copy_license))::
            "@@DistributePolicy@@result_success@@&TRACKINGKEY&@@Propagate promises@@None@@$(g.execRun)##$(g.uuid)@#No file need to be propagated";

Could you explain the duplication of tools_propagated ?

And in promises.cf, you made a modification that implies that every managed node will have the file /etc/rsyslog.d/rudder-agent.conf edited (even if there is not rsyslog on the system)

    !policy_server::
            "/etc/rsyslog.d/rudder-agent.conf" 
                edit_line => append_if_no_lines("#Rudder log system$(const.n)if $syslogfacility-text == 'local6' and $programname startswith 'rudder' then @@$(server_info.cfserved):514"),
                create => "true",
                edit_defaults => empty_backup,
                classes => class_trigger("rsyslog_repaired" , "rsyslog_failed", "rsyslog_kept");

Actions

Copy link

#13

Updated by Nicolas PERRON over 11 years ago

Nicolas CHARLES wrote:

Nicolas, I find these reports very dubious in propagatepromises.st
[...]

Could you explain the duplication of tools_propagated ?

We alaways need reports, even if no tools has been propagated. If it is not needed, this is still a success otherwise it will result in a 'no answer' state.

And in promises.cf, you made a modification that implies that every managed node will have the file /etc/rsyslog.d/rudder-agent.conf edited (even if there is not rsyslog on the system)
[...]

If you look above, you will see that:

[...]
  files:
    linux.rsyslogd::
[...]
        !policy_server::
            "/etc/rsyslog.d/rudder-agent.conf" 
                edit_line => append_if_no_lines("#Rudder log system$(const.n)if $syslogfacility-text == 'local6' and $programname startswith 'rudder' then @@$(server_info.cfserved):514"),
                create => "true",
                edit_defaults => empty_backup,
                classes => class_trigger("rsyslog_repaired" , "rsyslog_failed", "rsyslog_kept");
[...]

Then, only systm with rsyslog will have this file edited.

Actions

Copy link

#14

Updated by Nicolas CHARLES over 11 years ago

Nicolas PERRON wrote:

Nicolas CHARLES wrote:

Nicolas, I find these reports very dubious in propagatepromises.st
[...]

Could you explain the duplication of tools_propagated ?

We alaways need reports, even if no tools has been propagated. If it is not needed, this is still a success otherwise it will result in a 'no answer' state.

Indeed, we always need reports, but that's the logical expression that puzzles me :
(tools_propagated|tools_propagated.something) looks dubious; condition|condition.something should be written condition.something

And in promises.cf, you made a modification that implies that every managed node will have the file /etc/rsyslog.d/rudder-agent.conf edited (even if there is not rsyslog on the system)
[...]

If you look above, you will see that:
[...]

Then, only systm with rsyslog will have this file edited.

No,it doesn't work like that, there is "inheritance" in classes evaluation

Actions

Copy link

#15

Updated by Nicolas PERRON over 11 years ago

Status changed from In progress to Pending technical review
% Done changed from 80 to 100

Actions

Copy link

#16

Updated by Nicolas CHARLES over 11 years ago

Status changed from Pending technical review to Released

This looks valid, thank you Nicolas !

Actions

Copy link

#17

Updated by Jonathan CLARKE over 8 years ago

Related to Bug #6648: "Update" component of common technique sometimes return unexpected status and has incomplete reporting added

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

Rudder

Custom queries

Bug #2755

The server node doesn't seems to send some reports: common/update, common/log system for reports distributePolicy

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Matthieu CERDA over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas CHARLES over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas CHARLES over 11 years ago

Updated by Nicolas PERRON over 11 years ago

Updated by Nicolas CHARLES over 11 years ago

Updated by Jonathan CLARKE over 8 years ago