summaryrefslogtreecommitdiff
path: root/libpod/container_api.go
Commit message (Collapse)AuthorAge
* Merge pull request #14720 from sstosh/rm-optionopenshift-ci[bot]2022-06-29
|\ | | | | Fix: Prevent OCI runtime directory remain
| * Fix: Prevent OCI runtime directory remainToshiki Sonoda2022-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug was introduced in https://github.com/containers/podman/pull/8906. When we use 'podman rm/restart/stop/kill etc...' command to the container running with --rm, the OCI runtime directory remains at /run/<runtime name> (root user) or /run/user/<user id>/<runtime name> (rootless user). This bug could cause other bugs. For example, when we checkpoint the container running with --rm (podman checkpoint --export) and restore it (podman restore --import) with crun, error message "Error: OCI runtime error: crun: container `<container id>` already exists" is outputted. This error is caused by an attempt to restore the container with the same container ID as the remaining OCI runtime's container ID. Therefore, I fix that the cleanupRuntime() function runs to remove the OCI runtime directory, even if the container has already been removed by --rm option. Signed-off-by: Toshiki Sonoda <sonoda.toshiki@fujitsu.com>
* | libpod: fix wait and exit-code logicValentin Rothberg2022-06-23
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit addresses three intertwined bugs to fix an issue when using Gitlab runner on Podman. The three bug fixes are not split into separate commits as tests won't pass otherwise; avoidable noise when bisecting future issues. 1) Podman conflated states: even when asking to wait for the `exited` state, Podman returned as soon as a container transitioned to `stopped`. The issues surfaced in Gitlab tests to fail [1] as `conmon`'s buffers have not (yet) been emptied when attaching to a container right after a wait. The race window was extremely narrow, and I only managed to reproduce with the Gitlab runner [1] unit tests. 2) The clearer separation between `exited` and `stopped` revealed a race condition predating the changes. If a container is configured for autoremoval (e.g., via `run --rm`), the "run" process competes with the "cleanup" process running in the background. The window of the race condition was sufficiently large that the "cleanup" process has already removed the container and storage before the "run" process could read the exit code and hence waited indefinitely. Address the exit-code race condition by recording exit codes in the main libpod database. Exit codes can now be read from a database. When waiting for a container to exit, Podman first waits for the container to transition to `exited` and will then query the database for its exit code. Outdated exit codes are pruned during cleanup (i.e., non-performance critical) and when refreshing the database after a reboot. An exit code is considered outdated when it is older than 5 minutes. While the race condition predates this change, the waiting process has apparently always been fast enough in catching the exit code due to issue 1): `exited` and `stopped` were conflated. The waiting process hence caught the exit code after the container transitioned to `stopped` but before it `exited` and got removed. 3) With 1) and 2), Podman is now waiting for a container to properly transition to the `exited` state. Some tests did not pass after 1) and 2) which revealed the third bug: `conmon` was executed with its working directory pointing to the OCI runtime bundle of the container. The changed working directory broke resolving relative paths in the "cleanup" process. The "cleanup" process error'ed before actually cleaning up the container and waiting "main" process ran indefinitely - or until hitting a timeout. Fix the issue by executing `conmon` with the same working directory as Podman. Note that fixing 3) *may* address a number of issues we have seen in the past where for *some* reason cleanup processes did not fire. [1] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119#note_970712864 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com> [MH: Minor reword of commit message] Signed-off-by: Matthew Heon <mheon@redhat.com>
* Merge pull request #14384 from mheon/move_attachOpenShift Merge Robot2022-06-02
|\ | | | | Move Attach under the OCI Runtime interface
| * Move Attach under the OCI Runtime interfaceMatthew Heon2022-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With conmon-rs on the horizon, we need to disentangle Libpod from legacy Conmon to the greatest extent possible. There are definitely opportunities for codesharing between the two, but we have to assume the implementations will be largely disjoint given the different architectures. Fortunately, most of the work has already been done in the past. The conmon-managed OCI runtime mostly sits behind an interface, with a few exceptions - the most notable of those being attach. This PR thus moves Attach behind the interface, to ensure that we can have attach implementations that don't use our existing unix socket streaming if necessary. Still to-do is conmon cleanup. There's a lot of code that removes Conmon-specific files, or kills the Conmon PID, and all of it will need to be refactored behind the interface. [NO NEW TESTS NEEDED] Just moving some things around. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* | Add API support for NoOverwriteDirNonDirJhon Honce2022-05-26
| | | | | | | | | | | | | | | | | | | | | | | | Update method signatures and structs to pass option to buildah code ```release-note NONE ``` [NO NEW TESTS NEEDED] Signed-off-by: Jhon Honce <jhonce@redhat.com>
* | First batch of resolutions to FIXMEsMatthew Heon2022-05-25
|/ | | | | | | | | Most of these are no longer relevant, just drop the comments. Most notable change: allow `podman kill` on paused containers. Works just fine when I test it. Signed-off-by: Matthew Heon <mheon@redhat.com>
* enable gocritic linterPaul Holzinger2022-04-26
| | | | | | | | | | | | | | | | | | | | | | The linter ensures a common code style. - use switch/case instead of else if - use if instead of switch/case for single case statement - add space between comment and text - detect the use of defer with os.Exit() - use short form var += "..." instead of var = var + "..." - detect problems with append() ``` newSlice := append(orgSlice, val) ``` This could lead to nasty bugs because the orgSlice will be changed in place if it has enough capacity too hold the new elements. Thus we newSlice might not be a copy. Of course most of the changes are just cosmetic and do not cause any logic errors but I think it is a good idea to enforce a common style. This should help maintainability. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* enable unparam linterPaul Holzinger2022-04-25
| | | | | | | The unparam linter is useful to detect unused function parameters and return values. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* Add support for checkpoint imageRadostin Stoyanov2022-04-20
| | | | | | | | | | | | | | | | | | | | | | | | This is an enhancement proposal for the checkpoint / restore feature of Podman that enables container migration across multiple systems with standard image distribution infrastructure. A new option `--create-image <image>` has been added to the `podman container checkpoint` command. This option tells Podman to create a container image. This is a standard image with a single layer, tar archive, that that contains all checkpoint files. This is similar to the current approach with checkpoint `--export`/`--import`. This image can be pushed to a container registry and pulled on a different system. It can also be exported locally with `podman image save` and inspected with `podman inspect`. Inspecting the image would display additional information about the host and the versions of Podman, criu, crun/runc, kernel, etc. `podman container restore` has also been extended to support image name or ID as input. Suggested-by: Adrian Reber <areber@redhat.com> Signed-off-by: Radostin Stoyanov <radostin@redhat.com>
* fix a number of errcheck issuesValentin Rothberg2022-03-22
| | | | | | Numerous issues remain, especially in tests/e2e. Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
* bump go module to version 4Valentin Rothberg2022-01-18
| | | | | | | | | | | | | Automated for .go files via gomove [1]: `gomove github.com/containers/podman/v3 github.com/containers/podman/v4` Remaining files via vgrep [2]: `vgrep github.com/containers/podman/v3` [1] https://github.com/KSubedi/gomove [2] https://github.com/vrothberg/vgrep Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Add --file-locks checkpoint/restore optionRadostin Stoyanov2021-11-18
| | | | | | | | CRIU supports checkpoint/restore of file locks. This feature is required to checkpoint/restore containers running applications such as MySQL. Signed-off-by: Radostin Stoyanov <radostin@redhat.com>
* Added optional container restore statisticsAdrian Reber2021-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the parameter '--print-stats' to 'podman container restore'. With '--print-stats' Podman will measure how long Podman itself, the OCI runtime and CRIU requires to restore a checkpoint and print out these information. CRIU already creates process restore statistics which are just read in addition to the added measurements. In contrast to just printing out the ID of the restored container, Podman will now print out JSON: # podman container restore --latest --print-stats { "podman_restore_duration": 305871, "container_statistics": [ { "Id": "47b02e1d474b5d5fe917825e91ac653efa757c91e5a81a368d771a78f6b5ed20", "runtime_restore_duration": 140614, "criu_statistics": { "forking_time": 5, "restore_time": 67672, "pages_restored": 14 } } ] } The output contains 'podman_restore_duration' which contains the number of microseconds Podman required to restore the checkpoint. The output also includes 'runtime_restore_duration' which is the time the runtime needed to restore that specific container. Each container also includes 'criu_statistics' which displays the timing information collected by CRIU. Signed-off-by: Adrian Reber <areber@redhat.com>
* Added optional container checkpointing statisticsAdrian Reber2021-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the parameter '--print-stats' to 'podman container checkpoint'. With '--print-stats' Podman will measure how long Podman itself, the OCI runtime and CRIU requires to create a checkpoint and print out these information. CRIU already creates checkpointing statistics which are just read in addition to the added measurements. In contrast to just printing out the ID of the checkpointed container, Podman will now print out JSON: # podman container checkpoint --latest --print-stats { "podman_checkpoint_duration": 360749, "container_statistics": [ { "Id": "25244244bf2efbef30fb6857ddea8cb2e5489f07eb6659e20dda117f0c466808", "runtime_checkpoint_duration": 177222, "criu_statistics": { "freezing_time": 100657, "frozen_time": 60700, "memdump_time": 8162, "memwrite_time": 4224, "pages_scanned": 20561, "pages_written": 2129 } } ] } The output contains 'podman_checkpoint_duration' which contains the number of microseconds Podman required to create the checkpoint. The output also includes 'runtime_checkpoint_duration' which is the time the runtime needed to checkpoint that specific container. Each container also includes 'criu_statistics' which displays the timing information collected by CRIU. Signed-off-by: Adrian Reber <areber@redhat.com>
* Ensure `podman ps --sync` functionsMatthew Heon2021-10-06
| | | | | | | | | | | | The backend for `ps --sync` has been nonfunctional for a long while now - probably since v2.0. It's questionable how useful the flag is in modern Podman (the original case it was intended to catch, Conmon gone via SIGKILL, should be handled now via pinging the process with a signal to ensure it's still alive) but having the ability to force a refresh of container state from the OCI runtime is still useful. Signed-off-by: Matthew Heon <mheon@redhat.com>
* Allow `podman stop` to be run on Stopping containersMatthew Heon2021-10-06
| | | | | | | | | | | | | | | | | This allows you to stop a container after a `podman stop` process started, but did not finish, stopping the container (probably an ignored stop signal, with no time to SIGKILL?). This is a very narrow case, but once you're in it the only way to recover is a `podman rm -f` of the container or extensive manual remediation (you'd have to kill the container yourself, manually, and then force a `podman ps --all --sync` to update its status from the OCI runtime). [NO NEW TESTS NEEDED] I have no idea how to verify this one - we need to test that it actually started *during* the other stop command, and that's nontrivial. Signed-off-by: Matthew Heon <mheon@redhat.com>
* logging: new mode -l passthroughGiuseppe Scrivano2021-09-27
| | | | | | | | | | it allows to pass the current std streams down to the container. conmon support: https://github.com/containers/conmon/pull/289 [NO TESTS NEEDED] it needs a new conmon. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
* standardize logrus messages to upper caseDaniel J Walsh2021-09-22
| | | | | | | | Remove ERROR: Error stutter from logrus messages also. [ NO TESTS NEEDED] This is just code cleanup. Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Merge pull request #10910 from ↵OpenShift Merge Robot2021-07-28
|\ | | | | | | | | adrianreber/2021-07-12-checkpoint-restore-into-pod Add support for checkpoint/restore into and out of pods
| * Support checkpoint/restore with podsAdrian Reber2021-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support to checkpoint containers out of pods and restore container into pods. It is only possible to restore a container into a pod if it has been checkpointed out of pod. It is also not possible to restore a non pod container into a pod. The main reason this does not work is the PID namespace. If a non pod container is being restored in a pod with a shared PID namespace, at least one process in the restored container uses PID 1 which is already in use by the infrastructure container. If someone tries to restore container from a pod with a shared PID namespace without a shared PID namespace it will also fail because the resulting PID namespace will not have a PID 1. Signed-off-by: Adrian Reber <areber@redhat.com>
* | support container to container copyMehul Arora2021-07-27
|/ | | | | | | | | Implement container to container copy. Previously data could only be copied from/to the host. Fixes: #7370 Co-authored-by: Mehul Arora <aroram18@mcmaster.ca> Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Implement --archive flag for podman cpMatej Vasek2021-07-01
| | | | Signed-off-by: Matej Vasek <mvasek@redhat.com>
* Add parameter to specify checkpoint archive compressionAdrian Reber2021-06-07
| | | | | | | | | | | | | | | The checkpoint archive compression was hardcoded to `archive.Gzip`. There have been requests to make the used compression algorithm selectable. There was especially the request to not compress the checkpoint archive to be able to create faster checkpoints when not compressing it. This also changes the default from `gzip` to `zstd`. This change should not break anything as the restore code path automatically handles whatever compression the user provides during restore. Signed-off-by: Adrian Reber <areber@redhat.com>
* turn hidden --trace into a NOPValentin Rothberg2021-03-08
| | | | | | | | | | The --trace has helped in early stages analyze Podman code. However, it's contributing to dependency and binary bloat. The standard go tooling can also help in profiling, so let's turn `--trace` into a NOP. [NO TESTS NEEDED] Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* podman cp: support copying on tmpfs mountsValentin Rothberg2021-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, the path resolution for containers has been resolved on the *host*; relative to the container's mount point or relative to specified bind mounts or volumes. While this works nicely for non-running containers, it poses a problem for running ones. In that case, certain kinds of mounts (e.g., tmpfs) will not resolve correctly. A tmpfs is held in memory and hence cannot be resolved relatively to the container's mount point. A copy operation will succeed but the data will not show up inside the container. To support these kinds of mounts, we need to join the *running* container's mount namespace (and PID namespace) when copying. Note that this change implies moving the copy and stat logic into `libpod` since we need to keep the container locked to avoid race conditions. The immediate benefit is that all logic is now inside `libpod`; the code isn't scattered anymore. Further note that Docker does not support copying to tmpfs mounts. Tests have been extended to cover *both* path resolutions for running and created containers. New tests have been added to exercise the tmpfs-mount case. For the record: Some tests could be improved by using `start -a` instead of a start-exec sequence. Unfortunately, `start -a` is flaky in the CI which forced me to use the more expensive start-exec option. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* prune remotecommand dependencybaude2021-02-25
| | | | | | | | | | | prune a dependency that was only being used for a simple struct. Should correct checksum issue on tarballs [NO TESTS NEEDED] Fixes: #9355 Signed-off-by: baude <bbaude@redhat.com>
* bump go module to v3Valentin Rothberg2021-02-22
| | | | | | | | | We missed bumping the go module, so let's do it now :) * Automated go code with github.com/sirkon/go-imports-rename * Manually via `vgrep podman/v2` the rest Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Fix per review requestMatej Vasek2021-02-04
| | | | Signed-off-by: Matej Vasek <mvasek@redhat.com>
* Improve container libpod.Wait*() functionsMatej Vasek2021-02-03
| | | | Signed-off-by: Matej Vasek <mvasek@redhat.com>
* libpod: add (*Container).ResolvePath()Valentin Rothberg2021-01-26
| | | | | | | | | Add an API to libpod to resolve a path on the container. We can refactor the code that was originally written for copy. Other functions are requiring a proper path resolution, so libpod seems like a reasonable home for sharing that code. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Merge pull request #8906 from vrothberg/fix-8501OpenShift Merge Robot2021-01-14
|\ | | | | container stop: release lock before calling the runtime
| * container stop: release lock before calling the runtimeValentin Rothberg2021-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Podman defers stopping the container to the runtime, which can take some time. Keeping the lock while waiting for the runtime to complete the stop procedure, prevents other commands from acquiring the lock as shown in #8501. To improve the user experience, release the lock before invoking the runtime, and re-acquire the lock when the runtime is finished. Also introduce an intermediate "stopping" to properly distinguish from "stopped" containers etc. Fixes: #8501 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* | add pre checkpointunknown2021-01-10
|/ | | | Signed-off-by: Zhuohan Chen <chen_zhuohan@163.com>
* Include named volumes in container migrationRadostin Stoyanov2021-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When migrating a container with associated volumes, the content of these volumes should be made available on the destination machine. This patch enables container checkpoint/restore with named volumes by including the content of volumes in checkpoint file. On restore, volumes associated with container are created and their content is restored. The --ignore-volumes option is introduced to disable this feature. Example: # podman container checkpoint --export checkpoint.tar.gz <container> The content of all volumes associated with the container are included in `checkpoint.tar.gz` # podman container checkpoint --export checkpoint.tar.gz --ignore-volumes <container> The content of volumes is not included in `checkpoint.tar.gz`. This is useful, for example, when the checkpoint/restore is performed on the same machine. # podman container restore --import checkpoint.tar.gz The associated volumes will be created and their content will be restored. Podman will exit with an error if volumes with the same name already exist on the system or the content of volumes is not included in checkpoint.tar.gz # podman container restore --ignore-volumes --import checkpoint.tar.gz Volumes associated with container must already exist. Podman will not create them or restore their content. Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
* SpellingJosh Soref2020-12-22
| | | | Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
* Implement pod-network-reloadMatthew Heon2020-12-07
| | | | | | | | | | | | | | | | | | | | | | | This adds a new command, 'podman network reload', to reload the networks of existing containers, forcing recreation of firewall rules after e.g. `firewall-cmd --reload` wipes them out. Under the hood, this works by calling CNI to tear down the existing network, then recreate it using identical settings. We request that CNI preserve the old IP and MAC address in most cases (where the container only had 1 IP/MAC), but there will be some downtime inherent to the teardown/bring-up approach. The architecture of CNI doesn't really make doing this without downtime easy (or maybe even possible...). At present, this only works for root Podman, and only locally. I don't think there is much of a point to adding remote support (this is very much a local debugging command), but I think adding rootless support (to kill/recreate slirp4netns) could be valuable. Signed-off-by: Matthew Heon <matthew.heon@pm.me> Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
* Allow containers to --restart on-failure with --rmDaniel J Walsh2020-11-20
| | | | Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Ensure that attach ready channel does not blockMatthew Heon2020-10-28
| | | | | | | | | | | | We only use this channel in terminal attach, and it was not a buffered channel originally, so it would block on trying to send unless a receiver was ready. In the non-terminal case, there was no receiver, so attach blocked forever. Buffer the channel for a single bool so that it will never block, even if unused. Fixes #8154 Signed-off-by: Matthew Heon <mheon@redhat.com>
* Force Attach() to send a SIGWINCH and redrawMatthew Heon2020-09-10
| | | | | | | | | | | | | | | | | | Basically, we want to force the application in the container to (iff the container was made with a terminal) redraw said terminal immediately after an attach completes, so the fresh Attach session will be able to see what's going on (e.g. will have a shell prompt). Our current attach functions are unfortunately geared more towards `podman run` than `podman attach` and will start forwarding resize events *immediately* instead of waiting until the attach session is alive (much safer for short-lived `podman run` sessions, but broken for the `podman attach` case). To avoid a major rewrite, let's just manually send a SIGWINCH after attach succeeds to force a redraw. Fixes #6253 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* Send HTTP Hijack headers after successful attachMatthew Heon2020-08-27
| | | | | | | | | | | | | | | | | | | | | | | | | Our previous flow was to perform a hijack before passing a connection into Libpod, and then Libpod would attach to the container's attach socket and begin forwarding traffic. A problem emerges: we write the attach header as soon as the attach complete. As soon as we write the header, the client assumes that all is ready, and sends a Start request. This Start may be processed *before* we successfully finish attaching, causing us to lose output. The solution is to handle hijacking inside Libpod. Unfortunately, this requires a downright extensive refactor of the Attach and HTTP Exec StartAndAttach code. I think the result is an improvement in some places (a lot more errors will be handled with a proper HTTP error code, before the hijack occurs) but other parts, like the relocation of printing container logs, are just *bad*. Still, we need this fixed now to get CI back into good shape... Fixes #7195 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* Switch all references to github.com/containers/libpod -> podmanDaniel J Walsh2020-07-28
| | | | Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Remove all instances of named return "err" from LibpodMatthew Heon2020-07-09
| | | | | | | | | | | | | | | | | This was inspired by https://github.com/cri-o/cri-o/pull/3934 and much of the logic for it is contained there. However, in brief, a named return called "err" can cause lots of code confusion and encourages using the wrong err variable in defer statements, which can make them work incorrectly. Using a separate name which is not used elsewhere makes it very clear what the defer should be doing. As part of this, remove a large number of named returns that were not used anywhere. Most of them were once needed, but are no longer necessary after previous refactors (but were accidentally retained). Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* log API: add context to allow for cancellingValentin Rothberg2020-07-09
| | | | | | | | | Add a `context.Context` to the log APIs to allow for cancelling streaming (e.g., via `podman logs -f`). This fixes issues for the remote API where some go routines of the server will continue writing and produce nothing but heat and waste CPU cycles. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* move go module to v2Valentin Rothberg2020-07-06
| | | | | | | | | | | | | | | With the advent of Podman 2.0.0 we crossed the magical barrier of go modules. While we were able to continue importing all packages inside of the project, the project could not be vendored anymore from the outside. Move the go module to new major version and change all imports to `github.com/containers/libpod/v2`. The renaming of the imports was done via `gomove` [1]. [1] https://github.com/KSubedi/gomove Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Allow recursive dependency start with Init()Matthew Heon2020-06-18
| | | | | | | | | | | | | | | | | | | | As part of APIv2 Attach, we need to be able to attach to freshly created containers (in ContainerStateConfigured). This isn't something Libpod is interested in supporting, so we use Init() to get the container into ContainerStateCreated, in which attach is possible. Problem: Init() will fail if dependencies are not started, so a fresh container in a fresh pod will fail. The simplest solution is to extend the existing recursive start code from Start() to Init(), allowing dependency containers to be started when we initialize the container (optionally, controlled via bool). Also, update some comments in container_api.go to make it more clear how some of our major API calls work. Fixes #6646 Signed-off-by: Matthew Heon <mheon@redhat.com>
* Turn on More lintersDaniel J Walsh2020-06-15
| | | | | | | | | - misspell - prealloc - unparam - nakedret Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* WIP V2 attach bindings and testJhon Honce2020-05-13
| | | | | | | | * Add ErrLostSync to report lost of sync when de-mux'ing stream * Add logus.SetLevel(logrus.DebugLevel) when `go test -v` given * Add context to debugging messages Signed-off-by: Jhon Honce <jhonce@redhat.com>
* Improve APIv2 support for AttachMatthew Heon2020-04-13
| | | | | | | | | | | | | | A few major fixes here: - Support for attaching to Configured containers, to match Docker behavior. - Support for stream parameter has been improved (we now properly handle cases where it is not set). - Initial support for logs parameter has been added. - Setting attach streams when the container has a terminal is now supported. - Errors are properly reported once the hijack has begun. Signed-off-by: Matthew Heon <mheon@redhat.com>
* v2podman attach and execBrent Baude2020-04-05
| | | | | | | | add the ability to attach to a running container. the tunnel side of this is not enabled yet as we have work on the endpoints and plumbing to do yet. add the ability to exec a command in a running container. the tunnel side is also being deferred for same reason. Signed-off-by: Brent Baude <bbaude@redhat.com>