Rudder

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

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 | 

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

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.

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 ?

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.

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