Cri-o: OCI hooks ignore if /etc/containers/oci/hooks.d is missing

[baichinger]

---

BUG REPORT INFORMATION

Description

OCI hooks do not get executed if /etc/containers/oci/hooks.d does not exist. As hooks in this directory just override hooks from hooks_dir_path this should be optional.

Steps to reproduce the issue:

1. Install CRI-O
2. Create a hook in hooks_dir_path = "/usr/share/containers/oci/hooks.d"
3. Restart crio service

Describe the results you received:

crio[15828]: level=debug msg="reading hooks from /usr/share/containers/oci/hooks.d"
crio[15828]: level=debug msg="added hook /usr/share/containers/oci/hooks.d/test.json"
crio[15828]: level=debug msg="reading hooks from /etc/containers/oci/hooks.d"
crio[15828]: level=warning msg="failed to load hooks: open /etc/containers/oci/hooks.d: no such file or directory"

Provided hooks in /usr/share/containers/oci/hooks.d are ignored.

Describe the results you expected:

Hooks in hooks_dir_path should be used even though the override directory /etc/containers/oci/hooks.d does not exist.

Additional information you deem important (e.g. issue happens only occasionally):

Rather than using a single value hooks_dir_path and the implicit location /etc/containers/oci/hooks.d for overrides, it would be more obvious to use a list of directories. This list could implicitly define the priority of hooks.

Output of crio --version:

crio version 1.12.1-dev
commit: ""

Additional environment details (AWS, VirtualBox, physical, etc.):

CRI-O setup instructions used: https://kubernetes.io/docs/setup/cri/#cri-o

# lsb_release -d
Description:    Ubuntu 16.04 LTS

[mheon]

@wking Do you figure https://github.com/containers/libpod/pull/1920 will fix this issue?

[baichinger]

Looks promising as non-existing directories will be ignored by https://github.com/containers/libpod/pull/1920/files#diff-87d2459bf706cdc9058fa08c9223faceR1207.

[wking]

@wking Do you figure containers/libpod#1920 will fix this issue?

Yeah. I can port it to CRI-O once it lands in libpod.

[wking]

Looking into this now, seems like 50539c31c0 (#1749) made hooks_dir_path public. What are folks feelings for backwards compat there? It would be nice to be able to follow libpod with hooks_dir taking an array of strings, but I dunno if need to keep the exiting hooks_dir_path around or not.

[baichinger]

Hi @wking. Thanks for fixing this!
Is there any chance to get this merged into 1.12 as well?

[zvonkok]

Asking here as well, any chance to get this merged into 1.12?