summaryrefslogtreecommitdiff
path: root/libpod/define
diff options
context:
space:
mode:
authorMatthew Heon <mheon@redhat.com>2020-06-17 15:31:53 -0400
committerMatthew Heon <matthew.heon@pm.me>2020-06-18 09:34:04 -0400
commitb20619e5b0dfa6c63b25c3fd9a7ae6188bee2b4c (patch)
tree440ba00f0400d44da8b19024f852978ed67ff2e0 /libpod/define
parent3eb0ad04a8b1d56866a16f1428bb8019927ccfa3 (diff)
downloadpodman-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/define')
0 files changed, 0 insertions, 0 deletions