Rudder

I'll look into this.

Nicolas CHARLES wrote:

We need to factorize it a bit, and be sure of what we do (sometimes we handle disable-agent, sometimes not)

Regarding the disable-agent feature, what currently is implemented is:

• The cron entry will not re*start cf-execd or cf-agent if it is *already stopped and the disable-agent file exists
• The promises will not re*start cf-execd or cf-serverd if they are *already stopped and the disable-agent file exists

However, we never actually stop a running agent when disable-agent is touched. This should be changed. A nice approach would be to have a bundle that does something like this:

  classes:
    "should_disable_agent" expression => fileexists("${g.rudder_base}/etc/disable-agent");
    "disable_agent" 
      expression => "should_disable_agent",
      ifvarclass => "abort_report_done";

  processes:
    "cf-execd, cf-serverd, cf-monitord" 
       attributes => kill them;

  reports:
    should_disable_agent::
      "Report saying OMG the server and executor have been stopped, and the agent is going to be killed!" 
         classes => if_ok("abort_report_done");

This ticket is actually about two different things:

1. The fact that CFEngine process checking is split across various bundles in our code. This is a refactoring task, which I will leave in this ticket (new ticket type: Architecture) and target it for next major release.
2. The bug that "disable-agent" touch-file doesn't actually stop a running agent, it just stops cf-execd from being from being restarted (big difference). I will open a new ticket for this.

I don't think this change could be made for Rudder 2.8

All the process management is now done by rudder agent check