diff options
| author | Matthew Heon <mheon@redhat.com> | 2020-06-17 15:31:53 -0400 |
|---|---|---|
| committer | Matthew Heon <matthew.heon@pm.me> | 2020-06-18 09:34:04 -0400 |
| commit | b20619e5b0dfa6c63b25c3fd9a7ae6188bee2b4c (patch) | |
| tree | 440ba00f0400d44da8b19024f852978ed67ff2e0 /libpod/container_inspect.go | |
| parent | 3eb0ad04a8b1d56866a16f1428bb8019927ccfa3 (diff) | |
| download | podman-b20619e5b0dfa6c63b25c3fd9a7ae6188bee2b4c.tar.gz podman-b20619e5b0dfa6c63b25c3fd9a7ae6188bee2b4c.tar.bz2 podman-b20619e5b0dfa6c63b25c3fd9a7ae6188bee2b4c.zip | |
Allow recursive dependency start with Init()
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>
Diffstat (limited to 'libpod/container_inspect.go')
0 files changed, 0 insertions, 0 deletions