Bug #4291


Reporting with NCF on components that mustn't be executed everytime

Added by Nicolas CHARLES almost 9 years ago. Updated 4 months ago.

Generic methods
Target version:
UX impact:
User visibility:
Effort required:


I tried to create a Technique, with a component that is not to be run everytime (restarting a service if configuration file are updated)
The problem is that I don't have reporting with it when nothing was done.

So I tried to create a component that would do two thing:
- define success class based on the prefix of the restart component
- make report based on this restart

However, since I don't want it to declare that it does reporting, I can't rudderify it (I left class_prefix and class_parameter empty so that I don't have an extra component in reporting)

I tried to put an _ in front of the name, to no avail.
Nicolas Perron suggested to pass the class condition to the restart component, that would restart if class_condition is true, otherwise do nothing; and report always.
This is a bit painful as we'll need to do it for every generic method (exemple: don't create file if package not installed, don't execute command if package not install, execute command only if file editied, etc etc)

What would be the 'canonical' solution (if any?) for this issue ?
Shouldn't we create a false component that does only reporting when nothing was to be done, and allow to call it from the 50_techniques ?

I'm putting this ticket in Rudder rather than NCF as it is linked to the usage of ncf with Rudder

Actions #1

Updated by Matthieu CERDA almost 9 years ago

  • Project changed from Rudder to 41
  • Category deleted (13)
  • Status changed from New to Discussion
  • Assignee changed from Matthieu CERDA to Nicolas CHARLES

We talked a bit about this with FAR.

It looks like a pretty large use case that might need to be improved not only in Rudder, but also maybe on ncf itself (for debugging purposes), but it requires some more thinking and I need more people to do that.

This is not blocking for Rudder 2.9.0 as ncf and Rudder are two separate entities, I propose to talk about this when everyone will be available.

Switching to ncf as it might also be useful to have this on ncf too :)

Actions #2

Updated by Jonathan CLARKE over 8 years ago

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:

    "package" usebundle => package_install(apache2);
    "config"  usebundle => file_copy("apache2.conf", "/etc/apache2/apache2.conf");
    "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?

Actions #3

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.9.0 to 2.9.1
Actions #4

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.9.1 to 0.x
Actions #5

Updated by Nicolas CHARLES over 7 years ago

  • Status changed from Discussion to Rejected

Ok, the right solution is to create manually the report
It is handled automatically by the web interface, so i'm rejecting this ticket as solved

Actions #6

Updated by Alexis Mousset 4 months ago

  • Target version changed from 0.x to ncf-0.x
  • Priority set to 0
Actions #7

Updated by Alexis Mousset 4 months ago

  • Project changed from 41 to Rudder
  • Category set to Generic methods

Also available in: Atom PDF