W. Trevor King b2344b83ed pkg/ctime: Factor libpod/finished* into a separate package
This removes some boilerplate from the libpod package, so we can focus
on container stuff there.  And it gives us a tidy sub-package for
focusing on ctime extraction, so we can focus on unit testing and
portability of the extraction utility there.

For the unsupported implementation, I'm falling back to Go's ModTime
[1].  That's obviously not the creation time, but it's likely to be
closer than the uninitialized Time structure from cc6f0e85 (more
changes to compile darwin, 2018-07-04, #1047).  Especially for our use
case in libpod/oci, where we're looking at write-once exit files.

The test is more complicated than I initially expected, because on
Linux filesystem timestamps come from a truncated clock without
interpolation [2] (and network filesystems can be completely decoupled
[3]).  So even for local disks, creation times can be up to a jiffie
earlier than 'before'.  This test ensures at least monotonicity by
creating two files and ensuring the reported creation time for the
second is greater than or equal to the reported creation time for the
first.  It also checks that both creation times are within the window
from one second earlier than 'before' through 'after'.  That should be
enough of a window for local disks, even if the kernel for those
systems has an abnormally large jiffie.  It might be ok on network
filesystems, although it will not be very resilient to network clock
lagging behind the local system clock.

[1]: https://golang.org/pkg/os/#FileInfo
[2]: https://groups.google.com/d/msg/linux.kernel/mdeXx2TBYZA/_4eJEuJoAQAJ
     Subject: Re: Apparent backward time travel in timestamps on file creation
     Date: Thu, 30 Mar 2017 20:20:02 +0200
     Message-ID: <tqMPU-1Sb-21@gated-at.bofh.it>
[3]: https://groups.google.com/d/msg/linux.kernel/mdeXx2TBYZA/cTKj4OBuAQAJ
     Subject: Re: Apparent backward time travel in timestamps on file creation
     Date: Thu, 30 Mar 2017 22:10:01 +0200
     Message-ID: <tqOyl-36A-1@gated-at.bofh.it>

Signed-off-by: W. Trevor King <wking@tremily.us>

Closes: #1050
Approved by: mheon
2018-07-06 17:54:32 +00:00
2018-05-14 13:30:39 +00:00
2018-07-06 00:49:56 +00:00
2018-05-15 17:35:11 +00:00
2017-11-01 11:24:59 -04:00
2018-06-29 15:59:22 -04:00
2018-05-04 17:15:55 +00:00
2018-06-29 00:28:27 +00:00
2018-06-05 19:31:13 +00:00
2018-06-29 15:59:12 -04:00
2018-01-18 07:01:48 -05:00
2018-06-29 15:25:21 +00:00
2017-11-01 11:01:27 -04:00
2018-05-17 17:48:51 +00:00
2017-11-01 11:24:59 -04:00
2017-11-17 02:07:18 +00:00

PODMAN logo

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 API Documentation on the Podman API using Varlink.

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 Troubleshooting Guide A list of common issues and solutions for Podman.

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.

Tutorials Tutorials on using Podman.

Contributing Information about contributing to this project.

Current Roadmap

  1. Varlink API for Podman
  2. Integrate libpod into CRI-O to replace its existing container management backend
  3. Pod commands for Podman
  4. Rootless containers
  5. Support for cleaning up containers via post-run hooks
Description
Podman: A tool for managing OCI containers and pods.
Readme Apache-2.0 273 MiB
Languages
Go 81.4%
Shell 13.5%
Perl 2%
Python 1.3%
PowerShell 0.8%
Other 0.9%