The new APIv2 branch provides an HTTP-based remote API to Podman.
The requirements of this are, unfortunately, incompatible with
the existing Attach API. For non-terminal attach, we need append
a header to what was copied from the container, to multiplex
STDOUT and STDERR; to do this with the old API, we'd need to copy
into an intermediate buffer first, to handle the headers.
To avoid this, provide a new API to handle all aspects of
terminal and non-terminal attach, including closing the hijacked
HTTP connection. This might be a bit too specific, but for now,
it seems to be the simplest approach.
At the same time, add a Resize endpoint. This needs to be a
separate endpoint, so our existing channel approach does not work
here.
I wanted to rework the rest of attach at the same time (some
parts of it, particularly how we start the Attach session and how
we do resizing, are (in my opinion) handled much better here.
That may still be on the table, but I wanted to avoid breaking
existing APIs in this already massive change.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When Libpod removes a container, there is the possibility that
removal will not fully succeed. The most notable problems are
storage issues, where the container cannot be removed from
c/storage.
When this occurs, we were faced with a choice. We can keep the
container in the state, appearing in `podman ps` and available for
other API operations, but likely unable to do any of them as it's
been partially removed. Or we can remove it very early and clean
up after it's already gone. We have, until now, used the second
approach.
The problem that arises is intermittent problems removing
storage. We end up removing a container, failing to remove its
storage, and ending up with a container permanently stuck in
c/storage that we can't remove with the normal Podman CLI, can't
use the name of, and generally can't interact with. A notable
cause is when Podman is hit by a SIGKILL midway through removal,
which can consistently cause `podman rm` to fail to remove
storage.
We now add a new state for containers that are in the process of
being removed, ContainerStateRemoving. We set this at the
beginning of the removal process. It notifies Podman that the
container cannot be used anymore, but preserves it in the DB
until it is fully removed. This will allow Remove to be run on
these containers again, which should successfully remove storage
if it fails.
Fixes#3906
Signed-off-by: Matthew Heon <mheon@redhat.com>
If the kube.yaml specifieds the SELinux type or Level, we need the container
to be launched with the correct label.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Refactor the `RuntimeConfig` along with related code from libpod into
libpod/config. Note that this is a first step of consolidating code
into more coherent packages to make the code more maintainable and less
prone to regressions on the long runs.
Some libpod definitions were moved to `libpod/define` to resolve
circular dependencies.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Currently podman play kube is not using the system default seccomp.json file.
This PR will use the default or override location for podman play.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We want to get podman info to tell us about the version of
the mount program to help us diagnose issues users are having.
Also if in rootless mode and slirp4netns is installed reveal package
info on slirp4netns.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
use the inotify backend to be notified on the container exit instead
of polling continuosly the runtime. Polling the runtime slowns
significantly down the podman execution time for short lived
processes:
$ time bin/podman run --rm -ti fedora true
real 0m0.324s
user 0m0.088s
sys 0m0.064s
from:
$ time podman run --rm -ti fedora true
real 0m4.199s
user 0m5.339s
sys 0m0.344s
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
the compilation demands of having libpod in main is a burden for the
remote client compilations. to combat this, we should move the use of
libpod structs, vars, constants, and functions into the adapter code
where it will only be compiled by the local client.
this should result in cleaner code organization and smaller binaries. it
should also help if we ever need to compile the remote client on
non-Linux operating systems natively (not cross-compiled).
Signed-off-by: baude <bbaude@redhat.com>
enable polling also when using inotify. It is generally useful to
have it as under high load inotify can lose notifications. It also
solves a race condition where the file is created while the watcher
is configured and it'd wait until the timeout and fail.
Closes: https://github.com/containers/libpod/issues/2942
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
We have a very high performance JSON library that doesn't need to
perform code generation. Let's use it instead of our questionably
performant, reflection-dependent deep copy library.
Most changes because some functions can now return errors.
Also converts cmd/podman to use jsoniter, instead of pkg/json,
for increased performance.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
prefer a fsnotify watcher to polling the file, we take advantage of
inotify on Linux and react more promptly to the PID file being
created.
If the watcher cannot be created, then fallback to the old polling
mechanism.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
don't wait for the timeout to expire if the runtime process exited.
I've noticed podman to hang on exit and keeping the container lock
taken when the OCI runtime already exited.
Additionally, it reduces the waiting time as we won't hit the 25
milliseconds waiting time in the worst case.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
prevent opening the same file twice, since we re-exec podman in
rootless mode. While at it, also solve a possible race between the
check for the file and writing to it. Another process could have
created the file in the meanwhile and we would just end up overwriting
it.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
unfortunately the papr CI system cannot test ubuntu as a VM; therefore,
this PR still keeps travis. but it does include fixes that will be required
for running on modern versions of ubuntu.
Signed-off-by: baude <bbaude@redhat.com>
Currently we add mounts from images, volumes and internal.
We can accidently over mount an existing mount. This patch sorts the mounts
to make sure a parent directory is always mounted before its content.
Had to change the default propagation on image volume mounts from shared
to private to stop mount points from leaking out of the container.
Also switched from using some docker/docker/pkg to container/storage/pkg
to remove some dependencies on Docker.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #1243
Approved by: mheon
Cull funcs from runtime_img.go which are no longer needed. Also, fix any remaining
spots that use the old image technique.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #532
Approved by: mheon
This represents the stage3 implementation for the image library. At this point, we
are moving the image-centric functions to pkg/image including migration of args and
object-oriented references. This is a not a one-for-one migration of funcs and some
funcs will need to continue to reside in runtime_img as they are overly specific to
libpod and probably not useful to others.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #484
Approved by: baude
Exec sessions now have an ID generated and assigned to their PID
and stored in the database state. This allows us to track what
exec sessions are currently active.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #412
Approved by: baude
--image-volumes tells podman what to do with the image volumes in the image config
There are 3 options: bind, tmpfs, and ignore
bind puts the volume contents in /var/lib/containers/storage/container-id/volumes/vol-dir
and bind mounts it into the container at /vol-dir
tmpfs mounts /vol-dir as a tmps into the container
ignore doesn't mount the image volumes onto the container
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #377
Approved by: rhatdan
Fixed the logic where we observed different performance
results when running an image by its fqname vs a shortname. In
the case of the latter, we resolve the name without using the
network.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #37
Approved by: rhatdan
