containers / podman

Podman: A tool for managing OCI containers and pods.

Podman: A tool for managing OCI containers and pods

Podman (the POD MANager) is a tool for managing containers and images, volumes mounted into those containers, and pods made from groups of containers. Podman runs containers on Linux, but can also be used on Mac and Windows systems using a Podman-managed virtual machine. Podman is based on libpod, a library for container lifecycle management that is also contained in this repository. The libpod library provides APIs for managing containers, pods, container images, and volumes.

All releases are GPG signed. Public keys of members of the team approved to make releases are located here.

• Continuous Integration:
  • 
  • GoDoc:
  • Downloads

Overview and scope

At a high level, the scope of Podman and libpod is the following:

• Support for multiple container image formats, including OCI and Docker images.
• Full management of those images, including pulling from various sources (including trust and verification), creating (built via Containerfile or Dockerfile or committed from a container), and pushing to registries and other storage backends.
• Full management of container lifecycle, including creation (both from an image and from an exploded root filesystem), running, checkpointing and restoring (via CRIU), and removal.
• Full management of container networking, using Netavark.
• Support for pods, groups of containers that share resources and are managed together.
• Support for running containers and pods without root or other elevated privileges.
• Resource isolation of containers and pods.
• Support for a Docker-compatible CLI interface, which can both run containers locally and on remote systems.
• No manager daemon, for improved security and lower resource utilization at idle.
• Support for a REST API providing both a Docker-compatible interface and an improved interface exposing advanced Podman functionality.
• Support for running on Windows and Mac via virtual machines run by podman machine.

Roadmap

1. Further improvements to podman machine to better support Podman Desktop and other developer usecases.
2. Support for conmon-rs, which will improve container logging.
3. Support for the BuildKit API.
4. Performance and stability improvements.
5. Reductions to the size of the Podman binary.

Communications

If you think you've identified a security issue in the project, please DO NOT report the issue publicly via the GitHub issue tracker, mailing list, or IRC. Instead, send an email with as many details as possible to [email protected]. This is a private mailing list for the core maintainers.

For general questions and discussion, please use Podman's channels.

For discussions around issues/bugs and features, you can use the GitHub issues and PRs tracking system.

There is also a mailing list at lists.podman.io. You can subscribe by sending a message to [email protected] with the subject subscribe.

Rootless

Podman can be easily run as a normal user, without requiring a setuid binary. When run without root, Podman containers use user namespaces to set root in the container to the user running Podman. Rootless Podman runs locked-down containers with no privileges that the user running the container does not have. Some of these restrictions can be lifted (via --privileged, for example), but rootless containers will never have more privileges than the user that launched them. If you run Podman as your user and mount in /etc/passwd from the host, you still won't be able to change it, since your user doesn't have permission to do so.

Almost all normal Podman functionality is available, though there are some shortcomings. Any recent Podman release should be able to run rootless without any additional configuration, though your operating system may require some additional configuration detailed in the install guide.

A little configuration by an administrator is required before rootless Podman can be used, the necessary setup is documented here.

Podman Desktop

Podman Desktop provides a local development environment for Podman and Kubernetes on Linux, Windows, and Mac machines. It is a full-featured desktop UI frontend for Podman which uses the podman machine backend on non-Linux operating systems to run containers. It supports full container lifecycle management (building, pulling, and pushing images, creating and managing containers, creating and managing pods, and working with Kubernetes YAML). The project develops on GitHub and contributors are welcome.

Out of scope

• Specialized signing and pushing of images to various storage backends. See Skopeo for those tasks.
• Support for the Kubernetes CRI interface for container management. The CRI-O daemon specializes in that.

OCI Projects Plans

Podman uses OCI projects and best of breed libraries for different aspects:

• Runtime: We use the OCI runtime tools to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like crun and runc.
• Images: Image management uses the containers/image library.
• Storage: Container and image storage is managed by containers/storage.
• Networking: Networking support through use of Netavark and Aardvark. Rootless networking is handled via slirp4netns.
• Builds: Builds are supported via Buildah.
• Conmon: Conmon is a tool for monitoring OCI runtimes, used by both Podman and CRI-O.
• Seccomp: A unified Seccomp policy for Podman, Buildah, and CRI-O.

Podman Information for Developers

For blogs, release announcements and more, please checkout the podman.io website!

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 REST API.

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.

Remote Client A brief how-to on using the Podman remote client.

Basic Setup and Use of Podman in a Rootless environment A tutorial showing the setup and configuration necessary to run Rootless Podman.

Release Notes Release notes for recent Podman versions.

Contributing Information about contributing to this project.

Buildah and Podman relationship

Buildah and Podman are two complementary open-source projects that are available on most Linux platforms and both projects reside at GitHub.com with Buildah here and Podman here. Both, Buildah and Podman are command line tools that work on Open Container Initiative (OCI) images and containers. The two projects differentiate in their specialization.

Buildah specializes in building OCI images. Buildah's commands replicate all of the commands that are found in a Dockerfile. This allows building images with and without Dockerfiles while not requiring any root privileges. Buildah’s ultimate goal is to provide a lower-level coreutils interface to build images. The flexibility of building images without Dockerfiles allows for the integration of other scripting languages into the build process. Buildah follows a simple fork-exec model and does not run as a daemon but it is based on a comprehensive API in golang, which can be vendored into other tools.

Podman specializes in all of the commands and functions that help you to maintain and modify OCI images, such as pulling and tagging. It also allows you to create, run, and maintain those containers created from those images. For building container images via Dockerfiles, Podman uses Buildah's golang API and can be installed independently from Buildah.

A major difference between Podman and Buildah is their concept of a container. Podman allows users to create "traditional containers" where the intent of these containers is to be long lived. While Buildah containers are really just created to allow content to be added back to the container image. An easy way to think of it is the buildah run command emulates the RUN command in a Dockerfile while the podman run command emulates the docker run command in functionality. Because of this and their underlying storage differences, you can not see Podman containers from within Buildah or vice versa.

In short, Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container cli commands. For more details, see the Container Tools Guide.

Podman Hello

$ podman run quay.io/podman/hello
Trying to pull quay.io/podman/hello:latest...
Getting image source signatures
Copying blob a6b3126f3807 done
Copying config 25c667d086 done
Writing manifest to image destination
Storing signatures
!... Hello Podman World ...!

         .--"--.
       / -     - \
      / (O)   (O) \
   ~~~| -=(,Y,)=- |
    .---. /`  \   |~~
 ~/  o  o \~~~~.----. ~~
  | =(X)= |~  / (O (O) \
   ~~~~~~~  ~| =(Y_)=-  |
  ~~~~    ~~~|   U      |~~

Project:   https://github.com/containers/podman
Website:   https://podman.io
Documents: https://docs.podman.io
Twitter:   @Podman_io

podman's Issues

Add optional --destination for podman push

For podman push, we want the user to be able to optionally specify a destination for their image. This prevents us from having to re-tag the image before pushing. For example,

podman push --destination myregistry/foobar:latest foobar

Use Conmon to hold ports open for CNI iptables portmapping

For CNI's IPTables-based portmapping to work properly, ports on the host must be opened and held by something that lives as long as the container. As libpod/podman do not guarantee a running daemon, the easiest way to do this is to have Conmon open ports on the host if requested, and close them when it exits

Create a github issue template

We should have a github issue template like cri-o has

https://github.com/kubernetes-incubator/cri-o/blob/master/.github/ISSUE_TEMPLATE.md

podman can not recognize the image prepared by copyimg in RHEL7

Currently we use copyimg to prepare image for podman related tests. But seems this is not working in RHEL7 host.

There are two typical error messages caused by this problem:

1. image not found. Example(podman_inspect.bats):

✗ podman inspect image
(in test file test/podman_inspect.bats, line 16)
`[ "$status" -eq 0 ]' failed
error getting image "docker.io/library/alpine:latest": unable to locate image "docker.io/library/alpine:latest": image not known
No JSON object could be decoded

2. extra output in podman run command output which caused the ctr_id include more info than only the container id. Example(podman_import.bats):

not ok 1 podman import with source and reference
# (in test file test/podman_import.bats, line 21)
#   `[ "$status" -eq 0 ]' failed
# Trying to pull docker.io/library/alpine:latest...
# Getting image source signatures
# Copying blob sha256:ff3a5c916c92643ff77519ffa742d3ec61b7f591b6b7504599d95a4a41134e28
 1.97 MB / 1.97 MB [========================================================] 0s
# Copying config sha256:3fd9065eaf02feaf94d68376da52541925650b81698c53c6824d92ff63f98353
 1.48 KB / 1.48 KB [========================================================] 0s
# Writing manifest to image destination
# Storing signatures
# cb3359dfe108c3570f41dc2b099b7337040150a4189fe4bf7092e528f74b6f43
# too many arguments given, need 1 at most.
# bash: line 1: Getting: command not found
# bash: line 2: Copying: command not found
# bash: line 3: $'\r': command not found
# bash: line 4: Copying: command not found
# bash: line 5: $'\r': command not found
# bash: line 6: Writing: command not found
# bash: line 7: Storing: command not found
# bash: line 8: cb3359dfe108c3570f41dc2b099b7337040150a4189fe4bf7092e528f74b6f43: command not found
# cb3359dfe108c3570f41dc2b099b7337040150a4189fe4bf7092e528f74b6f43

The same test cases are working well in Fedora.

networking leak nsfs mounts

when using networking, we are leaking/not cleaning up nsfs mounts after the container stops.

for example, after running:

bin/podman --log-level=debug run -it --rm --network=bridge alpine ip a

a newly created mount of:

nsfs on /run/netns/cni-94a7ea7b-ebad-cff0-56d2-96d6be27db5c type nsfs (rw,seclabel)

remains after the container is done executing and removed.

`kpod run -p ..` does not bind the ports

Type

/kind bug

What is happening

I am trying to do port binding on my machine from container, but kpod does not bind the ports. Also kpod ps does not show the port information. When curled on the endpoint it fails obviously since the port is not bound.

Steps to reproduce:

# kpod run -d -p 8000:8000 centos python -m SimpleHTTPServer                             
Trying to pull ...Trying to pull docker.io/library/centos:latest...                            
Getting image source signatures                
Copying blob sha256:85432449fd0fabb6bef4772246d9b7948723275a4c7e4dee18728f28d79f1c2c           
 70.03 MB / 70.03 MB [=====================================================] 17s               
Copying config sha256:3fa822599e10c5f2080dcf647068c72022b111d31bbec0c5adb8a96e7eb5379b         
 1.82 KB / 1.82 KB [========================================================] 0s               
Writing manifest to image destination          
Storing signatures                             
ad60539f9cd3a6a29601ec1467c834ae554e6e07d5d6a9de6b67adbf78a43550                               

# kpod ps
CONTAINER ID   IMAGE                     COMMAND                      CREATED AT       STATUS              PORTS   NAMES
ad60539f9cd3   docker.io/centos:latest   python -m SimpleHTTPServer   11 seconds ago   Up 11 seconds ago           elated_hugle

# curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

Versions:

# kpod version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "e456c07813c5ccc6ccc81ad9a103e46e1b59b50c"
Built:         Wed Dec 13 15:48:19 2017
OS/Arch:       linux/amd64

# runc -v
runc version 1.0.0-rc4+dev
commit: 97b8bfe7fdea74d5e49b657013455a888328f04e
spec: 1.0.0

# rpm -aq | grep runc
runc-1.0.0-12.rc4.gitaea4f21.fc27.x86_64

# cat /etc/os-release 
NAME=Fedora
VERSION="27 (Cloud Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Cloud Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Cloud Edition"
VARIANT_ID=cloud

# getenforce 
Enforcing

podman top panics under certain conditions

Under certain conditions, podman top will panic with an index out of range error. To replicate:

sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \
                    -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \
                    -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \
                    registry.fedoraproject.org/f26/httpd /usr/bin/run-httpd

And then:

panic: runtime error: index out of range

goroutine 1 [running]:
main.psDataToPSParams(0xc42080e0d0, 0xb, 0xb, 0xc4203e0400, 0x8, 0x8, 0xc, 0x0, 0x0, 0x221d0de, ...)
	/home/cloud-user/src/github.com/projectatomic/libpod/_output/src/github.com/projectatomic/libpod/cmd/podman/top.go:151 +0x46e
main.topCmd(0xc420398160, 0x0, 0x0)
	/home/cloud-user/src/github.com/projectatomic/libpod/_output/src/github.com/projectatomic/libpod/cmd/podman/top.go:87 +0x3d9
github.com/projectatomic/libpod/vendor/github.com/urfave/cli.HandleAction(0x1ef65e0, 0x22cc488, 0xc420398160, 0x0, 0xc420248ba0)
	/home/cloud-user/src/github.com/projectatomic/libpod/_output/src/github.com/projectatomic/libpod/vendor/github.com/urfave/cli/app.go:501 +0xd2
github.com/projectatomic/libpod/vendor/github.com/urfave/cli.Command.Run(0x2218892, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2254845, 0x2c, 0x0, ...)
	/home/cloud-user/src/github.com/projectatomic/libpod/_output/src/github.com/projectatomic/libpod/vendor/github.com/urfave/cli/command.go:165 +0x505
github.com/projectatomic/libpod/vendor/github.com/urfave/cli.(*App).Run(0xc420762000, 0xc420010090, 0x3, 0x3, 0x0, 0x0)
	/home/cloud-user/src/github.com/projectatomic/libpod/_output/src/github.com/projectatomic/libpod/vendor/github.com/urfave/cli/app.go:259 +0x740
main.main()
	/home/cloud-user/src/github.com/projectatomic/libpod/_output/src/github.com/projectatomic/libpod/cmd/podman/main.go:155 +0x1112

It looks like the issue is around the default use of cmd in the ps options as removing that will allow it to work.

Podman build does not respect log-level flag

Podman build does not pass the --log-level global flag into Buildah, so debugging output will only occur for Podman itself.

I haven't checked, but I suspect other global flags are also not respected

kpod inspect fails to load container info

Type

/kind bug

What is happening

When I am trying to do inspect on a container, fails to open file in /var/lib/containers/storage/overlay-containers/$container-id/userdata/artifacts/create-config

Steps to reproduce:

# kpod run -d centos sleep 1000
c1c2d651ed5b6fd8179001258dae91e30ad0744b073f3575238adcf266772edc

# kpod ps
CONTAINER ID   IMAGE                             COMMAND      CREATED AT       STATUS              PORTS   NAMES
c1c2d651ed5b   docker.io/library/centos:latest   sleep 1000   23 seconds ago   Up 23 seconds ago           thirsty_goldstine

# kpod inspect thirsty_goldstine
error parsing container data %!q(func() string=0x1d5a8b0): error getting artifact "c1c2d651ed5b6fd8179001258dae91e30ad0744b073f3575238adcf266772edc": open /var/lib/containers/storage/overlay-containers/c1c2d651ed5b6fd8179001258dae91e30ad0744b073f3575238adcf266772edc/userdata/artifacts/create-config: no such file or directory

Versions:

# kpod version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "e456c07813c5ccc6ccc81ad9a103e46e1b59b50c"
Built:         Wed Dec 13 15:48:19 2017
OS/Arch:       linux/amd64

# runc -v
runc version 1.0.0-rc4+dev
commit: 97b8bfe7fdea74d5e49b657013455a888328f04e
spec: 1.0.0

# rpm -aq | grep runc
runc-1.0.0-12.rc4.gitaea4f21.fc27.x86_64

# cat /etc/os-release 
NAME=Fedora
VERSION="27 (Cloud Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Cloud Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Cloud Edition"
VARIANT_ID=cloud

# getenforce 
Enforcing

Merge libpod funcionality into CRI-O

It appears that buildah is limited to working on containers it creates itself. One direction we are considering for the OpenShift build side is to execute builds only within containers created by the existing runtime (crio or docker). Can buildah perform commands against other containers, and if not, what would it take to support that?

conmon path should include alternates

We should look for conmon in /usr/libexec/crio and /usr/local/libexec/crio. I'm also wondering about the reasoning of having a crio directory housing a single binary.

New default directory for credential files for kpod login?

Currently the default location for credential files for 'kpod login' is /etc/docker/certs.d/{registryname}. It would be nice to be able to change that to '/etc/oci/certs.d/{registryname}' or some other location that @rhatdan thinks is appropriate. The one caveat is we need to make sure that a private registry will run OK with this location in play.

podman does not support entrypoint

Steps to reproduce the issue:

This is just an example

1. buildah config --entrypoint "ls -al /etc" my-container

2. buildah inspect my-container // it's set correctly

3. buildah commit my-container ls

4. podman run -it ls

Describe the results you received:
You get an error asking you for a command

Describe the results you expected:
The long listing of a directory /etc

Additional information you deem important (e.g. issue happens only occasionally):

The entries in entrypoint are set correctly. Docker has no problem using them in the image.

Output of podman version:

podman version 0.1

Additional environment details (AWS, VirtualBox, physical, etc.):
Fedroa 27, physical

Add ability to load libpod default configuration from file

Similar to c/image and c/storage, libpod should load its default configuration in from a file, to allow unified system-wide container runtime settings to be honored by default

Potential symlink/directory traversal issue in user ID extraction

kpod inherited some configured-user to uid/gid resolution logic from buildah, so it also has this problem, which we're trying to solve in containers/buildah#313. We'll need a similar change here.

Name Reuse Errors when spawning many containers

Once you begin spawning large (~1000) numbers of containers, we begin to encounter name collisions with autogenerated names resulting in container creation failures. We should handle this sort of name collision gracefully, generating new candidate names until we find an unused one.

Tutorial using sudo when already su

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

Description

Steps to reproduce the issue:

Describe the results you received:

I see a lot of:

sudo

In the tutorials. But # assumes you are already root so why do the 'sudo'?

Describe the results you expected:
Either

$ sudo

or s/sudo //

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)

Additional environment details (AWS, VirtualBox, physical, etc.):

Reduce time spent on IO and Network during kpod tests

If we could preload images into a storage space and overlay them as test storage spaces, we could reduce the time spent doing IO and pulling images over the network. Every integration test for kpod gets a fresh/temporary storage space. So any test that uses and image, has to pull it now.

"CNI monitoring error" on master

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

Description

When running kpod built on master gives error of missing CNI and other unintuitive errors:

# ./bin/kpod ps
ERRO[0000] error updating cni config: Missing CNI default network 
ERRO[0000] Missing CNI default network                  
ERRO[0000] no such file or directory                    
ERRO[0000] CNI monitoring error <nil>

Steps to reproduce the issue:

Build:

# make
make -C conmon
make[1]: Entering directory '/root/go/src/github.com/projectatomic/libpod/conmon'
mkdir -p ../bin/
cc -o ../bin/conmon conmon.o cmsg.o -std=c99 -Os -Wall -Wextra -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -lglib-2.0 
make[1]: Leaving directory '/root/go/src/github.com/projectatomic/libpod/conmon'
go build -i -ldflags '-s -w -X main.gitCommit="f2f9fdf12674623dd0d38b32408083cccdad5e66" -X main.buildInfo=1513513523 -X main.kpodVersion=0.1' -tags "seccomp     selinux" -o bin/kpod github.com/projectatomic/libpod/cmd/kpod

Install:

# make install && make install.bin && make install.completions && make install.config && make install.man 
install -Z -D -m 755 bin/kpod /usr/local/bin/kpod
install -Z -D -m 755 bin/conmon /usr/local/libexec/crio/conmon
install -Z -d -m 755 /usr/local/share/man/man1
install -Z -m 644 docs/kpod-run.1 docs/kpod-diff.1 docs/kpod-create.1 docs/kpod-stats.1 docs/kpod-info.1 docs/kpod-stop.1 docs/kpod-ps.1 docs/kpod-kill.1 docs/kpod-wait.1 docs/kpod-import.1 docs/kpod-load.1 docs/kpod-logs.1 docs/kpod-images.1 docs/kpod-umount.1 docs/kpod.1 docs/kpod-push.1 docs/kpod-rm.1 docs/kpod-save.1 docs/kpod-cp.1 docs/kpod-login.1 docs/kpod-exec.1 docs/kpod-mount.1 docs/kpod-top.1 docs/kpod-inspect.1 docs/kpod-export.1 docs/kpod-tag.1 docs/kpod-history.1 docs/kpod-pause.1 docs/kpod-rmi.1 docs/kpod-start.1 docs/kpod-logout.1 docs/kpod-pull.1 docs/kpod-version.1 docs/kpod-attach.1 docs/kpod-unpause.1 -t /usr/local/share/man/man1
install -Z -D -m 755 bin/kpod /usr/local/bin/kpod
install -Z -D -m 755 bin/conmon /usr/local/libexec/crio/conmon
install -Z -d -m 755 /usr/local/share/bash-completion/completions
install -Z -m 644 -D completions/bash/kpod /usr/local/share/bash-completion/completions
install -Z -D -m 644 seccomp.json /etc/crio/seccomp.json
install -Z -D -m 644 crio-umount.conf /usr/local/share/oci-umount/oci-umount.d/crio-umount.conf
install -Z -d -m 755 /usr/local/share/man/man1
install -Z -m 644 docs/kpod-run.1 docs/kpod-diff.1 docs/kpod-create.1 docs/kpod-stats.1 docs/kpod-info.1 docs/kpod-stop.1 docs/kpod-ps.1 docs/kpod-kill.1 docs/kpod-wait.1 docs/kpod-import.1 docs/kpod-load.1 docs/kpod-logs.1 docs/kpod-images.1 docs/kpod-umount.1 docs/kpod.1 docs/kpod-push.1 docs/kpod-rm.1 docs/kpod-save.1 docs/kpod-cp.1 docs/kpod-login.1 docs/kpod-exec.1 docs/kpod-mount.1 docs/kpod-top.1 docs/kpod-inspect.1 docs/kpod-export.1 docs/kpod-tag.1 docs/kpod-history.1 docs/kpod-pause.1 docs/kpod-rmi.1 docs/kpod-start.1 docs/kpod-logout.1 docs/kpod-pull.1 docs/kpod-version.1 docs/kpod-attach.1 docs/kpod-unpause.1 -t /usr/local/share/man/man1

Output of kpod version:

version:

# ./bin/kpod version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "f2f9fdf12674623dd0d38b32408083cccdad5e66"
Built:         Sun Dec 17 12:22:42 2017
OS/Arch:       linux/amd64

Can't remove image created by Buildah

Is this a BUG REPORT or FEATURE REQUEST?:
kind bug

Description
An image created by Buildah is listed by Podman but can not be removed by Podman. It can be removed by Buildah and then it is no longer shown by Podman.

Steps to reproduce the issue:

1. buildah from alpine
2. podman images
3. podman rmi -f {imageid}

Describe the results you received:

# buildah from alpine
# podman images
REPOSITORY                 TAG      IMAGE ID       CREATED       SIZE
docker.io/library/alpine   latest   b908b128a5f6   4 weeks ago   4.14MB
# podman rmi -f b908b128a5f6
failed to remove image: Image used by 2b1024cf1d55d555af8ce15ed009fd9fb3c691c362d7a1c7c90107a0cf84371e: image is in use by a container
# podman ps --all
# buildah images
IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
b908b128a5f6         docker.io/library/alpine:latest                          Dec 1, 2017 18:48      3.954 MB
# buildah rmi -f b908b128a5f6
ERRO[0000] reference "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/b908b128a5f6:latest" does not resolve to an image ID 
b908b128a5f6172525f2fd0fed13ee5812ee168f45b623fc9955033568888153
# podman images

// Note the error from Buildah is a known error being tracked in https://github.com/projectatomic/buildah/issues/190

Describe the results you expected:
The image would be removed via Podman or the image in the list should somehow be marked as a Buildah image or otherwise non-deletable by Podman. It's more confusing as Podman says there are no containers when queried.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

# podman version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "ef4035e208f1431745cd044adb4b789fab3a98b6"
Built:         Tue Jan  2 08:27:22 2018
OS/Arch:       linux/amd64
# podman -v
podman version 0.1
# buildah -v
buildah version 0.9 (image-spec 1.0.0, runtime-spec 1.0.0)
# cat /etc/*release
Fedora release 27 (Twenty Seven)
NAME=Fedora
VERSION="27 (Server Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Server Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Server Edition"
VARIANT_ID=server
Fedora release 27 (Twenty Seven)
Fedora release 27 (Twenty Seven)

Additional environment details (AWS, VirtualBox, physical, etc.):

On a VM running Fedora 27 updated as of 1/2/2018

kpod built on fedora not usable in minikube

I am Building kpod in fedora 27

make install.tools 
make
sudo make install

kpod version:

$ kpod version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "195d48d86d871f531d72e0669ea96d315845da35"
Built:         Fri Nov 24 07:52:30 2017
OS/Arch:       linux/amd64

Now copying this built kpod to minikube machine to use there:

scp `which kpod` [email protected]:/home/docker/ 

Inside minikube vm

$ ./kpod -h
./kpod: error while loading shared libraries: libostree-1.so.1: cannot open shared object file: No such file or directory

I could not find much help of what should I be doing to get this binary workng in minikube vm.

Minikube VM OS info:

$ cat /etc/os-release 
NAME=Buildroot
VERSION=2017.02
ID=buildroot
VERSION_ID=2017.02
PRETTY_NAME="Buildroot 2017.02"

Remove Kubernetes hostport manager from Libpod

As the CNI plugins now provide independent hostport management, remove the Kubernetes implementation and provide CNI config files that will enable CNI hostport management.

Add function batching to the API

Right now, all public API endpoints for containers must do a syncContainer() which is a very expensive operation (hits runc and the database). We need a way to batch operations on a single container so syncContainer() is called once for a series of operations, to improve performance.

--net=none still needs completion

holiday reminder

Move away from file locks for containers and pods

As of now, we use file locks from containers/storage to synchronize operations between libpod in multiple processes. This comes with a number of serious issues

• We can't reap the locks when the container is removed
• Each lock is a file descriptor we have to keep open until the process closes

We need an alternative way of locking important container operations which does not have these limitations before we can seriously think of moving to CRI-O. Potential solution would be to rewrite file locking code to open the file in question immediately before acquiring the lock, and to close it immediately after the lock was released.

podman stop for a container takes 10s

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

Description

Everytime I run podman stop ... the command takes ~10s to run.

Steps to reproduce the issue:

1. start the container

# podman run -d alpine sleep 9999             
4ece26a2904da0184122f2540ed9810ddaaebdd4388b492b58c0cafc7c1b54c2                                         

2. see the running container

# podman ps
CONTAINER ID   IMAGE    COMMAND      CREATED AT                      STATUS             PORTS   NAMES
4ece26a2904d   alpine   sleep 9999   2018-02-06 16:40:50 +0000 UTC   Up 5 seconds ago           brave_hugle

3. stopping the container

# time podman stop brave_hugle                
4ece26a2904da0184122f2540ed9810ddaaebdd4388b492b58c0cafc7c1b54c2                                         

real    0m10.315s                                   
user    0m0.123s                                    
sys     0m0.049s                                    

Describe the results you received:

The deletion takes time.

Describe the results you expected:

Deletion can happen asynchronously (is that acheivable even though it is just a daemon)?

Output of podman version:

# podman version                              
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "bf00c976dd7509b7d84d1fa5254f1ac26fc494e5"
Built:         Tue Feb  6 14:58:14 2018
OS/Arch:       linux/amd64

Additional environment details (AWS, VirtualBox, physical, etc.):

# cat /etc/os-release 
NAME=Fedora
VERSION="27 (Cloud Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Cloud Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Cloud Edition"
VARIANT_ID=cloud

# runc -v
runc version 1.0.0-rc4+dev
commit: 97b8bfe7fdea74d5e49b657013455a888328f04e
spec: 1.0.0

CPU Profile

file:
podman-stop.zip

above was obtained as follows:

# podman --cpu-profile podman-stop stop jolly_lalande 
af7134f26e5bded8b3f08f15f44d9c0053561cb6a0b75b6226c29efa5cc5582c

# go tool pprof podman-stop          
File: podman                                                                                                                                                                                                       
Build ID: 177139ae37cef8148c544bc1ba759ca5b69c382b  
Type: cpu                                                                                                
Time: Feb 6, 2018 at 5:07pm (UTC)                                                                        
Duration: 10.28s, Total samples = 20ms ( 0.19%)     
Entering interactive mode (type "help" for commands, "o" for options)
...

image meta data missing in inspect

When pulling an image from the fedora repository, there is a bunch of missing metadata according to inspect. One question is if the metadata is present or missing or if podman just doesnt display it. A good example image to test with is registry.fedoraproject.org/f26/httpd:latest.

Labels for example are missing. Also, many ENV variables are also missing

            "Labels": {
                "Architecture": "x86_64",
                "BZComponent": "httpd",
                "Name": "f26/httpd",
                "Release": "2.f26container",
                "Version": "0",
                "architecture": "x86_64",
                "authoritative-source-url": "registry.example.com",
                "build-date": "2017-09-21T20:07:46.595262",
                "com.redhat.build-host": "osbs-node02.phx2.fedoraproject.org",
                "com.redhat.component": "httpd",
                "description": "Apache httpd 2.4 available as docker container, is a powerful, efficient, and extensible web server. Apache supports a variety of features, many implemented as compiled modules which extend the core functionality. These can range from server-side programming language support to authentication schemes. Virtual hosting allows one Apache installation to serve many different Web sites.",
                "distribution-scope": "private",
                "help": "help.1",
                "io.k8s.description": "Platform for running Apache httpd 2.4 or building httpd-based application",
                "io.k8s.display-name": "Apache httpd 2.4",
                "io.openshift.expose-services": "8080:http,8443:https",
                "io.openshift.s2i.scripts-url": "image:///usr/libexec/s2i",
                "io.openshift.tags": "builder,httpd,httpd24",
                "io.s2i.scripts-url": "image:///usr/libexec/s2i",
                "license": "MIT",
                "name": "f26/httpd",
                "release": "2.f26container",
                "summary": "Platform for running Apache httpd 2.4 or building httpd-based application",
                "usage": "docker run -d --name httpd -p 8080:8080 -v /wwwdata:/var/www:Z 26/httpd",
                "vcs-ref": "0f643ef80c30071b17c6c3c86fb4a5e98d5f07db",
                "vcs-type": "git",
                "vendor": "Fedora Project",
                "version": "0"
            }

do not log travis in #cri-o channel

https://github.com/projectatomic/libpod/blob/master/.travis.yml#L59

Can you guys change it to kpod channel? I see this in cri-o channel:

08:22         travis-ci : projectatomic/libpod#271 (auto - 2858100 : TomSweeneyRedHat): The build passed.
08:22         travis-ci : Change view : https://github.com/projectatomic/libpod/compare/5cfd7a313fca...28581007a906
08:22         travis-ci : Build details : https://travis-ci.org/projectatomic/libpod/builds/303521442

kpod load always try to pull image

# ./bin/kpod load -i nginx.tar
Trying to pull docker.io/library/nginx:latest...
Getting image source signatures
Copying blob sha256:cec7521cdf36a6d4ad8f2e92e41e3ac1b6fa6e05be07fa53cc84a63503bc5700
 55.73 MB / 55.73 MB [======================================================] 0s
Copying blob sha256:350d50e58b6cb4cef21d4b4a3460e82c3221bad93b31175c2cc387f744f3b5c2
 51.27 MB / 51.27 MB [======================================================] 0s
Copying blob sha256:63c39cd4a7759b03edef476bba3d3cd9ab377b3a71cba12586a506c9e94427b5
 3.50 KB / 3.50 KB [========================================================] 0s
Copying config sha256:9e7424e5dbaeb9b28fea44d8c75b41ac6104989b49b2464b7cbbed16ceeccfc3
 5.70 KB / 5.70 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
# ./bin/kpod --version
kpod version 0.1

kpod rm doesn't remove container created by Buildah

kpod rm fails when removing a container via it's name when the container is created by Buildah yet 'buildah rm' removes the container without an issue.

# CID=$(buildah from $TARGET)
# echo $CID
scratch-image-working-container
# buildah containers
CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
7b94f4b95eb4     *     87a2e5d48135 docker.io/library/scratch-image:latest scratch-image-working-container
# kpod rm $CID
no container with ID or name scratch-image-working-container found: no such container
unable to find container scratch-image-working-container: no container with ID or name scratch-image-working-container found: no such container
[root@docker test]# buildah rm $CID
7b94f4b95eb4a12a78f4e582bf1700e2a2c24f9978db634b1ac2dd34882afe97

`podman build -t` not accepting alpha numerics

Steps to reproduce the issue:

1. podman build -t <alphanumeric> .

Describe the results you received:
Container exits before commit and write. Thinks it is some sort of transport:reference ??

error building: error parsing reference for image to be written: Invalid image name "MyF27Base", expected colon-separated transport:reference
error running the buildah build-using-dockerfile (bud) command: exit status 1

Describe the results you expected:

COMMIT containers-storage:[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/MyF27Base:latest

Additional information you deem important (e.g. issue happens only occasionally):

buildah bud -t MyF27Base . 

seems to work

STEP 4: COMMIT containers-storage:[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/myf29base:latest

Output of podman version:

podman version 0.1

Additional environment details (AWS, VirtualBox, physical, etc.):
VirtualBox, F27 4.14.16-300.fc27.x86_64

Simple differences between podman inspect and docker inspect of container images.

Comparing inspect between

docker pull registry.fedoraproject.org/f26/httpd:latest
podman pull registry.fedoraproject.org/f26/httpd:latest

docker inspect registry.fedoraproject.org/f26/httpd:latest

podman inspect registry.fedoraproject.org/f26/httpd:latest

Quickly what I see.

Podman refers to "ID", while Docker refers to "Id", can we change this? or is this buried in container storage. Also Docker id has a sha256: prepended on it, while Podman does not?

The Config Section on Podman is referred to as ContainerConfig on Docker, I think this should change.

Docker shows a "hostname:" field equivalent to the shortname of the image, while podman does not show this field at all? Not sure this matters, since I don't know what a hostname for a container image means anyways.

Command field in podman is

    "Cmd": [
        "/usr/bin/run-httpd"
    ],

Docker:

        "Cmd": [
            "/bin/sh",
            "-c",
            "#(nop) USER [1001]"
        ],

Docker has an entrypoint field, while podman does not, Entrypoint=null?

portbinding issue with exposed ports

When an image has a port exposed, like 80, and we run:

podman run -d -P nginx

We do get a proper binding between the host and container, where the host is random -> port 80 on the container. But we also get a host binding of 80 -> 80 which is incorrect.

`kpod ps` execution time is proportional to number of containers

So while playing with kpod I realized that as the number of containers started by kpod increases so does the time of execution of kpod ps increases

# time ./bin/kpod ps
CONTAINER ID   IMAGE                             COMMAND       CREATED AT           STATUS                  PORTS   NAMES
be78432a43cd   docker.io/fedora:latest           sleep 50000   26 seconds ago       Up 26 seconds ago               fervent_joliot
a1da176ac999   docker.io/library/centos:latest   sleep 50000   About a minute ago   Up About a minute ago           elastic_wing

real    0m1.898s
user    0m0.176s
sys     0m0.084s


# time ./bin/kpod ps
CONTAINER ID   IMAGE                             COMMAND       CREATED AT           STATUS                  PORTS   NAMES
92e1409b964a   docker.io/library/fedora:latest   sleep 500     7 seconds ago        Up 7 seconds ago                quizzical_jones
be78432a43cd   docker.io/fedora:latest           sleep 50000   54 seconds ago       Up 54 seconds ago               fervent_joliot
a1da176ac999   docker.io/library/centos:latest   sleep 50000   About a minute ago   Up About a minute ago           elastic_wing

real    0m2.127s
user    0m0.189s
sys     0m0.177s

# time ./bin/kpod ps
CONTAINER ID   IMAGE                             COMMAND       CREATED AT           STATUS                  PORTS   NAMES
752e8878891d   docker.io/library/fedora:latest   sleep 5000    6 seconds ago        Up 6 seconds ago                nostalgic_engelbart
904d1a81a31d   docker.io/library/fedora:latest   sleep 5000    11 seconds ago       Up 11 seconds ago               amazing_pasteur
92e1409b964a   docker.io/library/fedora:latest   sleep 500     28 seconds ago       Up 28 seconds ago               quizzical_jones
be78432a43cd   docker.io/fedora:latest           sleep 50000   About a minute ago   Up About a minute ago           fervent_joliot
a1da176ac999   docker.io/library/centos:latest   sleep 50000   About a minute ago   Up About a minute ago           elastic_wing

real    0m3.079s
user    0m0.244s
sys     0m0.171s


# time ./bin/kpod ps
CONTAINER ID   IMAGE                             COMMAND       CREATED AT           STATUS                  PORTS   NAMES
676c3bff612b   docker.io/library/fedora:latest   sleep 5000    13 seconds ago       Up 13 seconds ago               reverent_minsky
bf28c1e5a34d   docker.io/library/fedora:latest   sleep 5000    18 seconds ago       Up 18 seconds ago               distracted_cori
5583c58681eb   docker.io/library/fedora:latest   sleep 5000    24 seconds ago       Up 24 seconds ago               dreamy_easley
be13daf108d7   docker.io/library/fedora:latest   sleep 5000    32 seconds ago       Up 32 seconds ago               gallant_wozniak
752e8878891d   docker.io/library/fedora:latest   sleep 5000    49 seconds ago       Up 49 seconds ago               nostalgic_engelbart
904d1a81a31d   docker.io/library/fedora:latest   sleep 5000    54 seconds ago       Up 54 seconds ago               amazing_pasteur
92e1409b964a   docker.io/library/fedora:latest   sleep 500     About a minute ago   Up About a minute ago           quizzical_jones
be78432a43cd   docker.io/fedora:latest           sleep 50000   About a minute ago   Up About a minute ago           fervent_joliot
a1da176ac999   docker.io/library/centos:latest   sleep 50000   2 minutes ago        Up 2 minutes ago                elastic_wing

real    0m5.319s
user    0m0.334s
sys     0m0.271s

Versions:

# ./bin/kpod version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "e456c07813c5ccc6ccc81ad9a103e46e1b59b50c"
Built:         Wed Dec 13 15:48:19 2017
OS/Arch:       linux/amd64

# cat /etc/os-release 
NAME=Fedora
VERSION="27 (Cloud Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Cloud Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Cloud Edition"
VARIANT_ID=cloud

Podman should support starting containers again after they have exited

Right now, conmon stops monitoring a container and exits once the container has exited. This means we cannot monitor containers once they have exited, so if a container is started again we cannot get its exit status (amongst other things). If we want to support restarting containers, we will need to add a way to start conmon that monitors runc but does not create the container in runc.

Support external network namespaces from podman run command.

A long time ago I opened a PR to support setting up a network namespace outside of Docker and have the container created by Docker join that network.

moby/libnetwork#372.

Upstream Docker rejected this... :^(
Let's get it into podman

Basically

podman run --net path:/PATH/TO/NETNS fedora sh

kpod cannot create container from image ID

# kpod images
IMAGE ID        IMAGE NAME                                 CREATED AT    SIZE
154c86301e152   registry.fedoraproject.org/fedora:latest   13 days ago   241.6 MB
54511612f1c4d   docker.io/gouyang/busybox:latest           9 weeks ago   1.34 MB
# kpod create
image name or ID is required
# kpod create 154c86301e152
Trying to pull /154c86301e152:latest...error parsing reference to image "/154c86301e152:latest": error parsing named reference "/154c86301e152:latest": invalid reference format

Processes in container can't catch SIGTERM

Reproducer:

kpod run -t -i --rm fedora:27 bash
In the container:
trap "echo Got SIGTERM" 15
Outside the container:
kpod kill $CONTAINER_ID

Expected behavior: the container prints "Got SIGTERM"
Actual behavior: the container exits, having not caught SIGTERM

Switch to containers/image master

Write now Nalin's fork of containers/image is vendored in. Once that is merged upstream, vendor in containers/image master instead.

Resolv.conf in a container is read-only

For containers created with podman run or podman create, resolv.conf is bind-mounted into the container read-only, which means it cannot be customized in a running container. This is undesirable.

copying of resolv.conf does not work on ubuntu

The current copying of resolv.conf when creating a container does not work correctly on ubuntu when it is using systemd-resolver.

kpod fails to find the runtime and is not obvious about it

So in my first attempt of bootstrapping a docker-like dev environment, I stumbled upon a weird issue that I couldn't start containers with kpod run. The symptom was as follows:

# kpod run -i --tty projectatomic/atomicapp  /bin/sh
ERRO[0000] Error removing container 4dd00aed2a714682abba1967cc4225878671ebc881f24726ae3bca55c5beacca from runc after creation failed 
error reading container (probably exited) json message: EOF

Now I must say first: not very helpful. It's a confusing error message: we are led to believe the problem is "removing container" when we're just trying to start one... (Obviously, it's a cleanup routine gone wrong, but still.) The real error message is actually buried inside conmon, and shows up in journalctl -f:

déc 11 14:04:58 curie conmon[21323]: conmon <ninfo>: addr{sun_family=AF_UNIX, sun_path=/tmp/conmon-term.3VLNAZ} 
déc 11 14:04:58 curie conmon[21323]: conmon <ninfo>: about to waitpid: 21324 
déc 11 14:04:58 curie conmon[21323]: conmon <error>: Failed to create container: exit status 127 

And well... that's still not very helpful. A few straces later, I found out that I could start containers by hand by firing up the runc command myself, so the problem wasn't there. I also tried running conmon by hand, and noticed it would return with an exit status of zero (0) even though the runc command fails, which also seems wrong.

Old UNIX geeks may have already figured out the issue at this point, thanks to the famous "exit status 127" which is the shell telling us it can't find the binary. And indeed, kpod hardcodes the runtime path in config.go:

https://github.com/projectatomic/libpod/blob/92818fdfb79a142566abb2876c67b23b8944b836/libkpod/config.go#L279

In containers/buildah#355 I filed an issue about how buildah doesn't correctly install runc (while building it). Since the build system installs everything in /usr/local, i fixed the Ubuntu/Debian install instructions to install runc there as well (in containers/buildah#354) which means that runc is in /usr/local/bin/runc. I would also argue that /usr/sbin/runc would be a better default for that command which is (currently) obviously designed to be ran as root.

But the exact path to the runtime shouldn't matter: conmon should look into the PATH and not rely on an absolute path to find the runtime. I have tried passing the runtime to kpod with --runtime=/usr/local/bin/runc and that works!

# kpod --runtime=/usr/local/bin/runc run  -i --tty projectatomic/atomicapp /bin/sh
sh-4.2# 

So, summary, I would suggest the following:

• better diagnostics when failing to start runtime (from conmon? kpod? both?)
• proper failure code from conmon if runc fails to start
• search for runc binary instead of absolute path (in config.go)
• proper $PATH resolution for the runc binary (in conmon?)

I think that covers it - thanks!

'kpod push' doesn't use default transport

If you don't specify a transport, kpod push doesn't default to a transport. It probably should default to "docker://" if a transport is not provided. A similar fix was made to Buildah at: containers/buildah#260

In the examples below, "docker://" is not specified as the transport in the first call and kpod push fails. It then completes when specified.

# kpod push --cert-dir /root/auth docker.io/library/alpine:latest dockreg.redhat.com:5000/my-alpine2
error getting destination imageReference for "dockreg.redhat.com:5000/my-alpine2": Invalid image name "dockreg.redhat.com:5000/my-alpine2", unknown transport "dockreg.redhat.com"
[root@localhost tmp]# kpod push --cert-dir /root/auth docker.io/library/alpine:latest docker://dockreg.redhat.com:5000/my-alpine2
Getting image source signatures

kpod run -i -t <image> <command> has no stdout

We are observing an error with kpod run where the the command output does not display anything to stdout unless preceeded by bash -c. An example would be:

kpod run -i -t fedora cat /etc/fedora-release.

The results of the command are being sent to the container log.

If I remove the conditional around https://github.com/projectatomic/libpod/blob/master/conmon/conmon.c#L698, stdout begins to work again. I suspect there is an issue with detecting what is a tty or not somewhere up from this but I wasn't able to put my finger on it yet.

Our call to conmon from kpod looks like:

DEBU[0001] running conmon: /usr/local/libexec/crio/conmon  args=[-c f5b28122ca709c28a1370b7bcd1d1d90fdd5f1c585dbb2e4e66b17a54b95d8ca -u f5b28122ca709c28a1370b7bcd1d1d90fdd5f1c585dbb2e4e66b17a54b95d8ca -r /usr/bin/runc -b /var/run/containers/storage/overlay-containers/f5b28122ca709c28a1370b7bcd1d1d90fdd5f1c585dbb2e4e66b17a54b95d8ca/userdata -p /var/run/containers/storage/overlay-containers/f5b28122ca709c28a1370b7bcd1d1d90fdd5f1c585dbb2e4e66b17a54b95d8ca/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/f5b28122ca709c28a1370b7bcd1d1d90fdd5f1c585dbb2e4e66b17a54b95d8ca/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket -t]

'kpod login' doesn't allow certificates to be in non-default directory

There's no way to specify a directory to 'kpod login' to have it grab the ssl certificates from. It always looks for the certificates at:

/etc/docker/certs.d/{registry location}

The --certs-dir and probably --tls-verify parameters used for push/pull should be added to 'kpod login' so a non-default directory can be used if desired.

kpod pull outputs `Trying to pull` twice

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

Description

When pulling image which does not exist kpod prints Trying to pull twice:

# ./bin/kpod run -d fedora sleep infinity
Trying to pull ...Trying to pull docker.io/library/fedora:latest...
Getting image source signatures
Copying blob sha256:a8ee583972c2295bb76704d4defe5116d5e4dd7ba3767aaa2cc8fcf71088ee06
 82.80 MB / 82.80 MB [======================================================] 9s
Copying config sha256:422dc563ca3260ad9ef5c47a1c246f5065d7f177ce51f4dd208efd82967ff182
 2.29 KB / 2.29 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
c04d70df883e24a10d2ecb9c9affe9c7d89f1b404c6bff1213fbcb5fd7811435

Describe the results you received:

Trying to pull ...Trying to pull docker.io/library/fedora:latest...

^^^ This line specifically.

Output of kpod version:

# ./bin/kpod version
Version:       0.1
Go Version:    go1.9.2
Git Commit:    "90d984ef9a16bea6168542689a98748d00457152"
Built:         Sun Dec 17 13:39:42 2017
OS/Arch:       linux/amd64

tutorial missing

the README file has this blurb:

Running pods and containers

Follow this tutorial to get started with KPOD.

"tutorial" is a broken link, and I couldn't find a tutorial in here either...

Parsing of --net= flag is broken

The --net flag presently accepts broken input without error. For example:
podman run -t -i --net=container fedora bash
This is an incomplete --net flag - the container ID or name must also be provided
It is presently accepted without issue.
I also cannot get any container ID out of the --net parser even when --net=container:<valid_id> is used.

kpod logs --tail flag doesn't work

When the tail flag is set for kpod logs, no output is given.

➜  ~ sudo kpod logs --tail 2 c91
2017/11/03 13:32:37 Seeked /var/log/crio/pods/f903e70f737f67e09405a3d2efe2bd052684e15f756a038feb28f20ac6641011/c91ef327b3777c93c608135a51e595d9c8c010770d049a39077197ffced092bb.log - &{Offset:2 Whence:2}

vs kpod logs without the tail flag

➜  ~ sudo kpod logs c91         
2017/11/03 13:33:26 Seeked /var/log/crio/pods/f903e70f737f67e09405a3d2efe2bd052684e15f756a038feb28f20ac6641011/c91ef327b3777c93c608135a51e595d9c8c010770d049a39077197ffced092bb.log - &{Offset:0 Whence:0}
2017-11-02T16:05:05.140456062-04:00 stdout 1:C 02 Nov 20:05:05.140 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2017-11-02T16:05:05.140456062-04:00 stdout 1:C 02 Nov 20:05:05.140 # Redis version=4.0.2, bits=64, commit=00000000, modified=0, pid=1, just started
2017-11-02T16:05:05.140456062-04:00 stdout 1:C 02 Nov 20:05:05.140 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
2017-11-02T16:05:05.141264162-04:00 stdout 1:M 02 Nov 20:05:05.141 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
2017-11-02T16:05:05.141264162-04:00 stdout 1:M 02 Nov 20:05:05.141 # Server can't set maximum open files to 10032 because of OS error: Operation not permitted.
2017-11-02T16:05:05.141264162-04:00 stdout 1:M 02 Nov 20:05:05.141 # Current maximum open files is 4096. maxclients has been reduced to 4064 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
2017-11-02T16:05:05.142466462-04:00 stdout 1:M 02 Nov 20:05:05.142 * Running mode=standalone, port=6379.
2017-11-02T16:05:05.142764996-04:00 stdout 1:M 02 Nov 20:05:05.142 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2017-11-02T16:05:05.142789664-04:00 stdout 1:M 02 Nov 20:05:05.142 # Server initialized
2017-11-02T16:05:05.142842374-04:00 stdout 1:M 02 Nov 20:05:05.142 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
2017-11-02T16:05:05.143046750-04:00 stdout 1:M 02 Nov 20:05:05.143 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
2017-11-02T16:05:05.143087041-04:00 stdout 1:M 02 Nov 20:05:05.143 * Ready to accept connections
2017-11-02T16:08:11.932548480-04:00 stdout 1:signal-handler (1509653291) Received SIGTERM scheduling shutdown...
2017-11-02T16:08:12.017862951-04:00 stdout 1:M 02 Nov 20:08:12.017 # User requested shutdown...
2017-11-02T16:08:12.017862951-04:00 stdout 1:M 02 Nov 20:08:12.017 * Saving the final RDB snapshot before exiting.
2017-11-02T16:08:12.022972360-04:00 stdout 1:M 02 Nov 20:08:12.022 * DB saved on disk
2017-11-02T16:08:12.023063960-04:00 stdout 1:M 02 Nov 20:08:12.022 # Redis is now ready to exit, bye bye...

Going through the code, I noticed that https://github.com/projectatomic/libpod/blob/master/libkpod/logs.go#L43 is returning 0 tail.Lines in the Tail struct when the SeekInfo is set.
I cannot figure out why no lines are being received. I can fix this if I can get some guidance on why this might be happening.

inspection of container is missing network information

When you inspect a container, it is missing network information like IP address.