Ability to disable hooks

[verdel]

We want to use a universal shell-operator image that contains a set of hooks. In different Kubernetes clusters, different sets of hooks need to be activated.

This can be done, for example, through environment variables, but if we return an empty JSON object or exit code 0 when calling a hook with the --config flag, we get the following error:

hook::config() {
if [ "$ENABLE_HOOK_CUSTOM_LOGGING_FLOW" == "true" ]; then
  cat <<EOF
{
  "configVersion":"v1",
  "kubernetes": [
    {
      "apiVersion": "logging.banzaicloud.io/v1beta1",
      "kind": "flow",
      "executeHookOnEvent": [
        "Added",
        "Modified"
      ],
    }
  ]
}
EOF
else
  exit 0
fi
}

{"level":"fatal","logger":"shell-operator","msg":"assemble shell operator","error":"initialize HookManager fail: MAIN Fatal: initialize hook manager: creating hook '100-custom-logging-flow/add_or_update_flow.sh': load hook '100-custom-logging-flow/add_or_update_flow.sh' config: 1 error occurred:\n\t*  should have at least 1 property\n\n\nhook --config output: ","time":"2025-03-09T11:50:25Z"}

Could a parameter like enabled be added in the hook-level settings to allow disabling specific hooks?

A similar question is present in the discussion.

[verdel]

I took a closer look at the operator’s source code and discovered that it is possible to disable hooks without modification.

In the hook configuration schema validation, it is specified that the required attribute is configVersion, and there must be at least two properties.
This means that we can respond to a hook trigger with the --config flag with the following configuration:

{
  "configVersion": "v1",
  "settings": {
    "executionMinInterval": "1s",
    "executionBurst": 1
  }
}

This configuration will pass validation, but the hook itself will not be added to the queue.

In fact, we are working with an imperfect validation schema, where the properties onStartup, schedule, kubernetes, kubernetesMutating, kubernetesValidating, kubernetesCustomResourceConversion should have been inside oneOf.

If the validation schema had been structured as I indicated above, this configuration would be invalid:

{
  "configVersion": "v1",
  "settings": {
    "executionMinInterval": "1s",
    "executionBurst": 1
  }
}

In this case, to disable the hook, we would need an additional property. However, for now, we can work around this by using the hack described above.