Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow recursive dependency start with Init() #6656

Merged
merged 1 commit into from
Jun 18, 2020

Conversation

mheon
Copy link
Member

@mheon mheon commented Jun 17, 2020

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

@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mheon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 17, 2020
@rhatdan
Copy link
Member

rhatdan commented Jun 17, 2020

LGTM

@baude
Copy link
Member

baude commented Jun 17, 2020

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 17, 2020
@baude
Copy link
Member

baude commented Jun 17, 2020

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 17, 2020
@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jun 18, 2020
@rhatdan
Copy link
Member

rhatdan commented Jun 18, 2020

Does this bug keep coming back?

@mheon
Copy link
Member Author

mheon commented Jun 18, 2020

Maybe I didn't rebase? Though I somewhat doubt that.

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 containers#6646

Signed-off-by: Matthew Heon <[email protected]>
@mheon
Copy link
Member Author

mheon commented Jun 18, 2020

Repushed

@mheon
Copy link
Member Author

mheon commented Jun 18, 2020

/hold cancel
We're green

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 18, 2020
@baude
Copy link
Member

baude commented Jun 18, 2020

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 18, 2020
@openshift-merge-robot openshift-merge-robot merged commit e6b9b3a into containers:master Jun 18, 2020
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 24, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

podman-remote: run --pod foo: error preparing container
5 participants