Rudder

I recall that when designing the ncf-rudder integration, we agreed (disappointedly) that for those cases where methods would not be executed, we would have to call rudder reporting manually, until we find a better solution. Something like this:

methods:
    "package" usebundle => package_install(apache2);
  package_install_apache2_ok::
    "config"  usebundle => file_copy("apache2.conf", "/etc/apache2/apache2.conf");
  !package_install_apache2_ok::
    "report"  usebundle => _rudder_report_something("result_success", "Apache2 wasn't installed so no need to update the config");

Obviously, this could be improved incrementally in many ways:

• Rudder should really support a "result_noop" type to indicated that this wasn't so much a "success" rather a "nothing".
• We could have a helper method to make the reporting call easier (that's kind of what my "_rudder_report_something" bundle name refers to)

However, this is ugly and cumbersome for the user writing a meta-technique, who should not have to worry about how to make Rudder shut up about reporting issues. This, I believe, is the core issue to be addressed in this ticket.

It seems to me that we could adapt the expected reports based on these conditions. When we build expected_reports.csv, we parse the whole CFEngine config file into JSON/Python data structures, so we know what class restrictions apply to each methods promise (both from class:: prefix notation and from ifvarclass). By using these, and adding them into the expected_reports.csv file, we could know the "context" of each expected report (in this example, "file_copy" has context "package_install_apache2_ok").

Then, we could run a special reports bundle at the end of each ncf run, that checks the negated context of all expected reports (so, "!package_install_apache2_ok" in this case) and, if that expression is true, sends a generic "result_noop" (currently "result_success") back to Rudder.

This is a simple example, but more complex ones would work too - using a prefix class notation (ie, sles10::) and an ifvarclass notation using a parameter (ie, "package_install_${apache2.package_name}") means the context class is sles10.package_install_${apache2.package_name}. The variable will be expanded when the others in expected_reports.csv are (at the start of a ncf run). The only limitation is that any variable references must be fully qualified (ie, ${bundle.var} and not just ${var}), but that is already the case for any reporting keys in ncf.

What do you think?