Skip to content

Fix kubePlay to actually wait on serviceContainer #17595

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Fix kubePlay to actually wait on serviceContainer #17595

wants to merge 1 commit into from

Conversation

umohnani8
Copy link
Member

If a service container was created for a pod, kube play was no longer waiting on it to exit before returning. Looks like this was introduced by #17469.

Kube play --wait will add tests that will help test this. Just want to fix this before anything is really affected.

[NO NEW TEST NEEDED]

Does this PR introduce a user-facing change?

None

@openshift-ci openshift-ci bot added release-note-none approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 21, 2023
@umohnani8
Copy link
Member Author

@vrothberg PTAL

vrothberg
vrothberg approved these changes Feb 21, 2023
View reviewed changes
Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 21, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: umohnani8, vrothberg

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:
  • OWNERS [umohnani8,vrothberg]

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

@umohnani8
Fix kubePlay to actually wait on serviceContainer
0c4c823 
If a service container was created for a pod, kube play
was no longer waiting on it to exit before returning.
Looks like this was introduced by
containers#17469.

Kube play --wait will add tests that will help test this.
Just want to fix this before anything is really affected.

[NO NEW TESTS NEEDED]

Signed-off-by: Urvashi Mohnani <[email protected]>
@rhatdan
Copy link
Member

rhatdan commented Feb 21, 2023

LGTM
But tests are not happy.

@umohnani8
Copy link
Member Author

@vrothberg looks like this patch is causing the service container to not be the main PID - I am not seeing how moving the wait out of the default case is causing this though.

@vrothberg
Copy link
Member

@vrothberg looks like this patch is causing the service container to not be the main PID - I am not seeing how moving the wait out of the default case is causing this though.

The PR isn't correct yet as it's waiting for the service container unconditionally. Sorry for not catching that during review.

So we have two conditions where we need to wait:

  1. User explicitly wants it via --wait.
  2. Podman is technically forced to when running inside of systemd and when at least one container uses a custom sdnotify policy. In that case, Podman needs to be the MAINPID.

To meet 1) we could add a new field to type PlayKubeOptions struct that indicates whether Podman should wait or not.

@umohnani8
Copy link
Member Author

Got it, I have included the fix in the play --wait PR then https://github.com/containers/podman/pull/16717/files#diff-d3fb054de60fb7550ae0554fc1c99ac63b8434f960b49b5b7f0352f1d0fcb8f0R364.

Closing this PR.

@umohnani8 umohnani8 closed this Feb 22, 2023
@umohnani8 umohnani8 deleted the service branch February 23, 2023 18:43
@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 8, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@vrothberg vrothberg vrothberg approved these changes

Assignees
No one assigned
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. release-note-none
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@umohnani8 @rhatdan @vrothberg