Bug #2755
closedThe server node doesn't seems to send some reports: common/update, common/log system for reports distributePolicy
Added by Nicolas PERRON about 12 years ago. Updated almost 12 years ago.
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
Updated by Nicolas PERRON about 12 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.
Updated by Nicolas PERRON about 12 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.
Updated by Nicolas PERRON about 12 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
Updated by Matthieu CERDA about 12 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.
Updated by Nicolas PERRON almost 12 years ago
The problem has not been fixed so we still need work on it. Technical review can't be considered as done.
Updated by Nicolas PERRON almost 12 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 |
Updated by Nicolas PERRON almost 12 years ago
It seems that it is related to a Webapp bug: #2817
Updated by Nicolas PERRON almost 12 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.
Updated by Nicolas PERRON almost 12 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 ?
Updated by Nicolas PERRON almost 12 years ago
- % Done changed from 90 to 50
The work on this ticket is far from being done.
Updated by Nicolas PERRON almost 12 years ago
- Status changed from In progress to Pending technical review
- % Done changed from 50 to 100
Applied in changeset commit:06e2da401f48b79acbc25e4f8166aeb457a187d1.
Updated by Nicolas CHARLES almost 12 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");
Updated by Nicolas PERRON almost 12 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.
Updated by Nicolas CHARLES almost 12 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
Updated by Nicolas PERRON almost 12 years ago
- Status changed from In progress to Pending technical review
- % Done changed from 80 to 100
Updated by Nicolas CHARLES almost 12 years ago
- Status changed from Pending technical review to Released
This looks valid, thank you Nicolas !
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