Bug #10623
Updated by François ARMAND about 5 years ago
I upgraded Rudder from 4.1.0 to 4.1.1 and I had a custom /opt/rudder/etc/hooks.d/policy-generation-node-ready/10-cf-promise-check file after upgrading, file was restored to default content, which was super surprising it should at least be documented so that I know it might punch me. me In fact, we should distinguish between several hooks provided by Rudder: - 1/ the one absolutly needed to make Rudder works, like `policy-generation-node-ready/90-change-perm`. These one need to be updated by rudder at each upgrade and made executable. And we should make I'm setting it clear in them that an user should not change them, - 2/ the one that a user can enable/disable. We still don't want the content to be modifiable by an user (to allow update and bug correction), as minor, but an user should be allowed to change its perm, like in the example in that ticket. In fact, Rudder should even provide an UI setting to allow the user to change the hook perms. - 3/ the one that we allow the user to modify. For case 3/, in fact, we don't want any like that, because by allowing it, we forbid forever bug correction. So for that case, we should advice the user to provide his own hook and fill a bug upstream. If we want the user to be able to parametrize a hook, the parameter must be in a non executable file "XX-hook-name.properties" (which should be sourced by the hook). Case 1/ is the current behavior (modulo the warning in hook content about the fact that the hook will be reseted on next upgrade). Case 2/ need to be handled. it feels major as upgrade doesn't go as planned