| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules. While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
`github.com/containers/libpod/v2`. The renaming of the imports
was done via `gomove` [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
Podman is blowing up with oci-umount hook, because
it was never rewritten to support the v1.0.0 value.
This PR adds support for the older version and cleans
up the hook handling.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
...to work for specific edge cases with a simpler solution.
Re-reads hooks directories after any changes are detected by the watchers.
Added monitoring test for adding a different invalid hook to primary directory.
Some issues with prior code:
- ReadDir would stop when it encounters an invalid hook, rather than registering an error but continuing to read the valid hook.
- Wouldn’t account for Rename and Chmod events.
- After doing a mv of the hooks file instead of rm, it would still think the hooks file is in the directory, but it has been moved to another location.
- If a hook file was renamed, it would register the renamed file as a separate hook and not delete the original, so it would then execute the hook twice - once for the renamed file, and once for the original name which it did not delete.
Signed-off-by: samc24 <sam.chaturvedi24@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Need to get some small changes into libpod to pull back into buildah
to complete buildah transition.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #1270
Approved by: mheon
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We've had logrus logging in the monitor code since it landed in
68eb128f (pkg/hooks: Version the hook structure and add 1.0.0 hooks,
2018-04-27, #686). This commit adds similar logging to the initial
hook.New() and Manager.Hooks() calls to make it easier to see if those
are working as expected.
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #887
Approved by: rhatdan
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The continue here is from 5676597f (hooks/read: Ignore IsNotExist for
JSON files in ReadDir, 2018-04-27, #686), where it was intended to
silently ignore missing JSON files. However, the old logic was also
silently ignoring not-exist errors from the os.Stat(hook.Hook.Path)
from 68eb128f (pkg/hooks: Version the hook structure and add 1.0.0
hooks, 2018-04-27, #686). This commit adjusts the check so JSON
not-exist errors continue to be silently ignored while hook executable
not-exist errors become fatal.
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #887
Approved by: rhatdan
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We aren't consuming this yet, but these pkg/hooks changes lay the
groundwork for future libpod changes to support post-exit hooks [1,2].
[1]: https://github.com/projectatomic/libpod/issues/730
[2]: https://github.com/opencontainers/runc/issues/1797
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #758
Approved by: rhatdan
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a .json file existed when we called ioutil.ReadDir but that file
has been removed by the time we get around to calling Read on it,
silently ignore the file. Iterating through all the files in the
directory shouldn't take particularly long, so this is an unlikely
corner case. And when it happens, silently ignoring the file gives
the same outcome as you'd have gotten if the parallel remove had
happened slightly earlier before the ioutil.ReadDir call.
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #686
Approved by: mheon
|
|
|
This shifts the matching logic out of libpod/container_internal and
into the hook package, where we can reuse it after vendoring into
CRI-O. It also adds unit tests with almost-complete coverage. Now
libpod is even more isolated from the hook internals, which makes it
fairly straightforward to bump the hook config file to 1.0.0. I've
dubbed the old format 0.1.0, although it doesn't specify an explicit
version. Motivation for some of my changes with 1.0.0:
* Add an explicit version field. This will make any future JSON
structure migrations more straightforward by avoiding the need for
version-guessing heuristics.
* Collect the matching properties in a new When sub-structure. This
makes the root Hook structure easier to understand, because you
don't have to read over all the matching properties when wrapping
your head around Hook.
* Replace the old 'hook' and 'arguments' with a direct embedding of
the runtime-spec's hook structure. This provides access to
additional upstream properties (args[0], env, and timeout) and
avoids the complication of a CRI-O-specific analog structure.
* Add a 'when.always' property. You can usually accomplish this
effect in another way (e.g. when.commands = [".*"]), but having a
boolean explicitly for this use-case makes for easier reading and
writing.
* Replace the previous annotations array with an annotations map. The
0.1.0 approach matched only the values regardless of key, and that
seems unreliable.
* Replace 'cmds' with 'when.commands', because while there are a few
ways to abbreviate "commands", there's only one way to write it out
in full ;). This gives folks one less thing to remember when
writing hook JSON.
* Replace the old "inject if any specified condition matches" with
"inject if all specified conditions match". This allows for more
precise targeting. Users that need more generous targeting can
recover the previous behavior by creating a separate 1.0.0 hook file
for each specified 0.1.0 condition.
I've added doc-compat support for the various pluralizations of the
0.1.0 properties. Previously, the docs and code were not in
agreement. More on this particular facet in [1].
I've updated the docs to point out that the annotations being matched
are the OCI config annotations. This differs from CRI-O, where the
annotations used are the Kubernetes-supplied annotations [2,3]. For
example, io.kubernetes.cri-o.Volumes [4] is part of CRI-O's runtime
config annotations [5], but not part of the Kubernetes-supplied
annotations CRI-O uses for matching hooks.
The Monitor method supports the CRI-O use-case [6]. podman doesn't
need it directly, but CRI-O will need it when we vendor this package
there.
I've used nvidia-container-runtime-hook for the annotation examples
because Dan mentioned the Nvidia folks as the motivation behind
annotation matching. The environment variables are documented in [7].
The 0.1.0 hook config, which does not allow for environment variables,
only works because runc currently leaks the host environment into the
hooks [8]. I haven't been able to find documentation for their usual
annotation trigger or hook-install path, so I'm just guessing there.
[1]: https://github.com/kubernetes-incubator/cri-o/pull/1235
[2]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L760
[3]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L772
[4]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/pkg/annotations/annotations.go#L97-L98
[5]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L830-L834
[6]: https://github.com/kubernetes-incubator/cri-o/pull/1345/
[7]: https://github.com/NVIDIA/nvidia-container-runtime/tree/v1.3.0-1#environment-variables-oci-spec
[8]: https://github.com/opencontainers/runc/pull/1738
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #686
Approved by: mheon
|
