summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChris Evich <cevich@redhat.com>2018-12-11 12:55:19 -0500
committerChris Evich <cevich@redhat.com>2018-12-12 10:56:18 -0500
commitd038497b09ac064fafe4f921c0fc43b828a707a3 (patch)
treef1b1a40ee98d5de95a2e3b8baa1fd6f0e2014872
parent8a3361f46c87933aff04c9acaaf48b7c130bc9d8 (diff)
downloadpodman-d038497b09ac064fafe4f921c0fc43b828a707a3.tar.gz
podman-d038497b09ac064fafe4f921c0fc43b828a707a3.tar.bz2
podman-d038497b09ac064fafe4f921c0fc43b828a707a3.zip
Fix documentation links and flow
Signed-off-by: Chris Evich <cevich@redhat.com>
-rw-r--r--README.md39
-rw-r--r--contrib/cirrus/README.md52
2 files changed, 50 insertions, 41 deletions
diff --git a/README.md b/README.md
index 640e298e4..865900c62 100644
--- a/README.md
+++ b/README.md
@@ -1,15 +1,15 @@
![PODMAN logo](logo/podman-logo-source.svg)
-# 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: [![Build Status](https://api.cirrus-ci.com/github/containers/libpod.svg)](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) [![Build Status](https://api.cirrus-ci.com/github/containers/libpod.svg)](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