-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
lib/container_server: Deprecate implicit hook directories
The previous approach was breaking when the default hook directory was missing [1]: 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" With this commit, I've deprecated the implicit defaults in favor of having users explicitly configure their hook directories (either via --hooks-dir on the command line or hooks_dir in their config file). This is similar to the recent containers/podman@a4b483c8 (libpod/container_internal: Deprecate implicit hook directories, 2018-12-02, containers/podman#1920). Different from the libpod implementation is that CRI-O is only loading the hook manager at this point, so we don't know if the hook directories actually have hooks that will apply to future container (or even if they have hooks at all). I've just warned about their existence if the directories exist, to help poke folks into migrating to explicitly-configured directories. Another difference is that we get a single manager, so we need to ensure the default directories will work before feeding them in. I'm now stat'ing them to check, which will address [1]. But that's racy, since the directory could exist at stat time but be gone by the time the manager tries to load it. I'm ok with the race, because that entire code path is deprecated anyway. There's no race for the "user explicitly asked me to load /whatever and now it's gone" case. Now that the default case is pre-checking, I've tightened 50d4993 (lib: Use libpod's hooks package, 2018-04-07, #1517)'s load-failure warning down to a fatal error. I've dropped the trailing "path" from the old, hidden --hooks-dir-path, because I think "dir(ectory)" is already enough context for "we expect a path argument". I consider this name change non-breaking because the old form was undocumented. I've also changed hooks_dir_path to hooks_dir and changed it from a string to a []string. That is potentially a breaking change because hooks_dir_path became publicly documented in 50539c3 (crio.conf(5): update manpage to the latest state, 2018-08-22, #1749). But it's only been a few months since it landed, and making that setting public was only one of a few changes it had made. So I'm reasonably optimistic that there aren't (m)any users explicitly setting hooks_dir_path yet, and haven't gone through the trouble of continuing to support the old setting. [1]: #1942 (comment) Signed-off-by: W. Trevor King <[email protected]>
- Loading branch information
Showing
8 changed files
with
50 additions
and
48 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters