Rudder

Hum. You're right.

It does not seem very grave, and it is easy to revert to previous behaviour. But perhaps we should add a migration script from * -> 4.1.

So, we are missing a migration script that is looking in property file, grep for the option set to /bin/true and is so, set a-x /opt/rudder/etc/hooks.d/policy-generation-node-ready/10-cf-promise-check (and perhaps remove the option from the file to not be misleading for users, replacing it with comment).

That being said, shouldn't the properties "rudder.community.checkpromises.command" and "rudder.nova.checkpromises.command" be completelly commented? It is misleading that they are still present, even in fresh install (it is good that there is a text talking about hooks,thought)

Indeed, they should be commented
However, I think we should replace the values in the script, not disabling it
However, how would it behave at upgrade ? Will it create a new script with .rpmnew, that would be executed also ?

OK, so after some more thought, the value may have been changed to something else than the default value or/bin/true, like something they wrote themself. It does not seem reliable on that case to try to change policy-generation-node-ready/10-cf-promise-check hook (because it is not intented to be), so I'm seeing two possibilities: disable policy-generation-node-ready/10-cf-promise-check, copy it into policy-generation-node-ready/11-user-cf-promise-check, sed in it the commands ; or write a big warning "you did something advanced for cf-promise, please write you hook in place (example in policy-generation-node-ready/10-cf-promise-check).

Nicolas CHARLES wrote:

However, how would it behave at upgrade ? Will it create a new script with .rpmnew, that would be executed also ?

The condition is for it to be executable, the name is not taken into account. So yes, if the .rpmnew file is executable, it will be executed.

In fact, we can always migrate with three cases:

- if the value of the property is the default value, do nothing,
- if the value of the property is /bin/true, disable the hook
- if the value is some other command, the implicit contract was that the command would receive the parameters "-f ${pathOfPromises}/promises.cf" so in this case, we just have to disable the existing hook and create a new hook as follow (modulo good shell skills:)

#!/bin/sh

# Hooks parameter are passed by environment variable: 
#
# - RUDDER_GENERATION_DATETIME    : generation datetime: ISO-8601 YYYY-MM-ddTHH:mm:ss.sssZ date/time that identify that policy generation start 
# - RUDDER_NODEID                 : the nodeId
# - RUDDER_NEXT_POLICIES_DIRECTORY: new policies directory (for ex for nodes under root: /var/rudder/share/$RUDDER_NODEID/rules.new)
# - RUDDER_AGENT_TYPE             : agent type ("cfengine-nova" or "cfengine-community")

HERE_NAME_OF_COMMAND_FROM_PROPERTY -f "${RUDDER_NEXT_POLICIES_DIRECTORY}/promises.cf" 

The same logic must be applied for property: rudder.cfengine.reload.server.command ; default value: /opt/rudder/bin/rudder-reload-cf-serverd ; if the value is not that one, then hook: /opt/rudder/hooks.d/policy-generation-finished/50-sigup-cf-serverd must be disabled and a new hook with the value created (no parameter expected).