Project

General

Profile

Actions

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:
1
Assignee:
Nicolas PERRON
Category:
System techniques
Target version:
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 open2 closed)

Related to Rudder - User story #1971: Impossible to manage rudder server via web interfaceReleasedNicolas PERRON2012-07-212012-07-21Actions
Related to Rudder - Bug #6648: "Update" component of common technique sometimes return unexpected status and has incomplete reportingReleasedBenoƮt PECCATTE2015-05-21Actions
Actions #1

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 #2

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 #3

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 #4

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 #5

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 #6

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 #7

Updated by Nicolas PERRON over 11 years ago

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

Actions #8

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 #9

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 #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 #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 #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 #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 #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 #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 #16

Updated by Nicolas CHARLES over 11 years ago

  • Status changed from Pending technical review to Released

This looks valid, thank you Nicolas !

Actions #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

Also available in: Atom PDF