diff options
| -rw-r--r-- | README.md | 39 | ||||
| -rw-r--r-- | contrib/cirrus/README.md | 52 |
2 files changed, 50 insertions, 41 deletions
@@ -1,15 +1,15 @@  -# libpod - library for running OCI-based containers in Pods -### Latest Version: 0.12.1 -### Status: Active Development +# Library and tool for running OCI-based containers in Pods -### Continuous Integration: [](https://cirrus-ci.com/github/containers/libpod) +Libpod provides a library for applications looking to use the Container Pod concept, +popularized by Kubernetes. libpod also contains the `podman` tool, for managing +Pods, Containers, and Container Images. -## What is the scope of this project? +* [Latest Version: 0.12.1](https://github.com/containers/libpod/releases/latest) +* [Continuous Integration:](contrib/cirrus/README.md) [](https://cirrus-ci.com/github/containers/libpod/master) -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. +## Overview and scope At a high level, the scope of libpod and podman is the following: @@ -19,11 +19,22 @@ At a high level, the scope of libpod and podman is the following: * Full management of container lifecycle * Support for pods to manage groups of containers together * Resource isolation of containers and pods. +* Integration with CRI-O to share containers and backend code. -## What is not in scope for this project? +## Roadmap -* Signing and pushing images to various image storages. See [Skopeo](https://github.com/containers/skopeo/). -* Container Runtimes daemons for working with Kubernetes CRIs. See [CRI-O](https://github.com/kubernetes-sigs/cri-o). We are working to integrate libpod into CRI-O to share containers and backend code with Podman. +1. Python frontend for Varlink API +1. Integrate libpod into CRI-O to replace its existing container management backend +1. Further work on the podman pod command +1. Further improvements on rootless containers +1. In-memory locking to replace file locks + +## Out of scope + +* Signing and pushing images to various image storages. + See [Skopeo](https://github.com/containers/skopeo/). +* Container Runtimes daemons for working with Kubernetes CRIs. + See [CRI-O](https://github.com/kubernetes-sigs/cri-o). ## OCI Projects Plans @@ -68,14 +79,6 @@ Release notes for recent Podman versions **[Contributing](CONTRIBUTING.md)** Information about contributing to this project. -## Current Roadmap - -1. Python frontend for Varlink API -1. Integrate libpod into CRI-O to replace its existing container management backend -1. Further work on the podman pod command -1. Further improvements on rootless containers -1. In-memory locking to replace file locks - [spec-hooks]: https://github.com/opencontainers/runtime-spec/blob/v2.0.1/config.md#posix-platform-hooks ## Buildah and Podman relationship diff --git a/contrib/cirrus/README.md b/contrib/cirrus/README.md index 436dc5257..e175479f1 100644 --- a/contrib/cirrus/README.md +++ b/contrib/cirrus/README.md @@ -66,6 +66,18 @@ task (pass or fail) is set based on the exit status of the last script to execut ### ``cache_images`` Task +Modifying the contents of cache-images is done by making changes to +one or more of the ``./contrib/cirrus/packer/*_setup.sh`` files. Testing +those changes currently requires adding a temporary commit to a PR that +updates ``.cirrus.yml``: + +* Remove all task sections except ``cache_images_task``. +* Remove the ``only_if`` condition and ``depends_on`` dependencies + +The new image names will be displayed at the end of output, assuming the build +is successful, at that point the temporary commit may be removed. Finally, +the new names may be used as ``image_name`` values in ``.cirrus.yml``. + ***N/B: Steps below are performed by automation*** 1. When a PR is merged (``$CIRRUS_BRANCH`` == ``master``), run another @@ -90,12 +102,6 @@ task (pass or fail) is set based on the exit status of the last script to execut 3. If successful, shut down each VM and create a new GCE Image named with the base image, and the commit sha of the merge. -***Note:*** The ``.cirrus.yml`` file must be manually updated with the new -images names, then the change sent in via a secondary pull-request. This -ensures that all the ``integration_testing`` tasks can pass with the new images, -before subjecting all future PRs to them. A workflow to automate this -process is described in comments at the end of the ``.cirrus.yml`` file. - ### Base-images Base-images are VM disk-images specially prepared for executing as GCE VMs. @@ -120,27 +126,27 @@ as the standard 'cloud-init' services. To produce new base-images, including an `image-builder-image` (used by the ``cache_images`` Task) some input parameters are required: - * ``GCP_PROJECT_ID``: The complete GCP project ID string e.g. foobar-12345 - identifying where the images will be stored. +* ``GCP_PROJECT_ID``: The complete GCP project ID string e.g. foobar-12345 + identifying where the images will be stored. - * ``GOOGLE_APPLICATION_CREDENTIALS``: A *JSON* file containing - credentials for a GCE service account. This can be [a service - account](https://cloud.google.com/docs/authentication/production#obtaining_and_providing_service_account_credentials_manually) - or [end-user - credentials](https://cloud.google.com/docs/authentication/end-user#creating_your_client_credentials] +* ``GOOGLE_APPLICATION_CREDENTIALS``: A *JSON* file containing + credentials for a GCE service account. This can be [a service + account](https://cloud.google.com/docs/authentication/production#obtaining_and_providing_service_account_credentials_manually) + or [end-user + credentials](https://cloud.google.com/docs/authentication/end-user#creating_your_client_credentials) - * ``RHEL_IMAGE_FILE`` and ``RHEL_CSUM_FILE`` complete paths - to a `rhel-server-ec2-*.raw.xz` and it's cooresponding - checksum file. These must be supplied manually because - they're not available directly via URL like other images. +* ``RHEL_IMAGE_FILE`` and ``RHEL_CSUM_FILE`` complete paths + to a `rhel-server-ec2-*.raw.xz` and it's cooresponding + checksum file. These must be supplied manually because + they're not available directly via URL like other images. - * ``RHSM_COMMAND`` contains the complete string needed to register - the VM for installing package dependencies. The VM will be de-registered - upon completion. +* ``RHSM_COMMAND`` contains the complete string needed to register + the VM for installing package dependencies. The VM will be de-registered + upon completion. - * Optionally, CSV's may be specified to ``PACKER_BUILDS`` - to limit the base-images produced. For example, - ``PACKER_BUILDS=fedora,image-builder-image``. +* Optionally, CSV's may be specified to ``PACKER_BUILDS`` + to limit the base-images produced. For example, + ``PACKER_BUILDS=fedora,image-builder-image``. If there is an existing 'image-builder-image' within GCE, it may be utilized to produce base-images (in addition to cache-images). However it must be |