mirror of https://github.com/containers/podman.git
4b22913e11
And add an argument to WithHooksDir to set it. If the hook dir doesn't exist, the new hooks package considers that a fatal error. When a podman caller sets --hooks-dir-path=/some/typoed/directory, a fatal error is more helpful than silently not loading any hooks. However, callers who call podman without setting --hooks-dir-path may not need hooks at all. We don't want to pester those callers with not-exist errors. With this commit, we: * Assume the caller knows what they're doing if they set --hooks-dir-path and set HooksDirNotExistFatal. * If the caller does not explicitly set --hooks-dir-path, assume they won't mind if the hook directory is missing and set HooksDirNotExistFatal false. We also considered checking for the directory's existence in the code calling WithHooksDir or from within WithHooksDir, but checks there would race with the underlying ioutil.ReadDir in the hooks package. By pushing the warn/error decision down into libpod's implementation, we avoid a racy "do we expect this to work once libpod gets to it?" pre-check. I've also added a check to error if WithHooksDir is called with an empty-string argument, because we haven't defined the semantics of that (is it clearing a previous value? Is it effectively the same as the current directory?). I agree with Matthew that a separate WithNoHooks, or a *string argument to WithHooks, or some such would be a better API for clearing previous values [1]. But for now, I'm just erroring out to fail early for callers who might otherwise be surprised that libpod ignores empty-string HooksDir. [1]: https://github.com/projectatomic/libpod/pull/686#issuecomment-385119370 Signed-off-by: W. Trevor King <wking@tremily.us> Closes: #686 Approved by: mheon |
||
|---|---|---|
| .copr | ||
| .github | ||
| .tool | ||
| cmd/podman | ||
| cni | ||
| completions/bash | ||
| contrib | ||
| docs | ||
| hack | ||
| libpod | ||
| logo | ||
| pkg | ||
| test | ||
| utils | ||
| vendor | ||
| version | ||
| .gitignore | ||
| .papr.sh | ||
| .papr.yml | ||
| .papr_prepare.sh | ||
| .travis.yml | ||
| API.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| Dockerfile.CentOS | ||
| Dockerfile.Fedora | ||
| LICENSE | ||
| Makefile | ||
| OWNERS | ||
| README.md | ||
| Vagrantfile | ||
| changelog.txt | ||
| code-of-conduct.md | ||
| commands.md | ||
| crio-umount.conf | ||
| docker | ||
| install.md | ||
| libpod.conf | ||
| seccomp.json | ||
| transfer.md | ||
| vendor.conf | ||
README.md
libpod - library for running OCI-based containers in Pods
Status: Active Development
What is the scope of this project?
libpod provides a library for applications looking to use the Container Pod concept popularized by Kubernetes. libpod also contains a tool called podman for managing Pods, Containers, and Container Images.
At a high level, the scope of libpod and podman is the following:
- Support multiple image formats including the existing Docker/OCI image formats.
- Support for multiple means to download images including trust & image verification.
- Container image management (managing image layers, overlay filesystems, etc).
- Full management of container lifecycle
- Support for pods to manage groups of containers together
- Resource isolation of containers and pods.
What is not in scope for this project?
- Signing and pushing images to various image storages. See Skopeo.
- Container Runtimes daemons for working with Kubernetes CRIs. See CRI-O. We are working to integrate libpod into CRI-O to share containers and backend code with Podman.
OCI Projects Plans
The plan is to use OCI projects and best of breed libraries for different aspects:
- Runtime: runc (or any OCI compliant runtime) and oci runtime tools to generate the spec
- Images: Image management using containers/image
- Storage: Container and image storage is managed by containers/storage
- Networking: Networking support through use of CNI
- Builds: Builds are supported via Buildah.
- Conmon: Conmon is a tool for monitoring OCI runtimes. It is part of the CRI-O package
Podman Information for Developers
Installation notes Information on how to install Podman in your environment.
OCI Hooks Support Information on how Podman configures OCI Hooks to run when launching a container.
Podman Commands A list of the Podman commands with links to their man pages and in many cases videos showing the commands in use.
Podman Usage Transfer Useful information for ops and dev transfer as it relates to infrastructure that utilizes Podman. This page includes tables showing Docker commands and their Podman equivalent commands.
Podman API Documentation on the Podman API using Varlink.
Tutorials Tutorials on using Podman.
Contributing Information about contributing to this project.
Current Roadmap
- Varlink API for Podman
- Integrate libpod into CRI-O to replace its existing container management backend
- Pod commands for Podman
- Rootless containers
- Support for cleaning up containers via post-run hooks