-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Ensure that podman play kube
actually reports errors
#8917
Ensure that podman play kube
actually reports errors
#8917
Conversation
[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 |
@containers/podman-maintainers PTAL |
pkg/domain/entities/play.go
Outdated
@@ -40,6 +40,9 @@ type PlayKubePod struct { | |||
Containers []string | |||
// Logs - non-fatal errors and log messages while processing. | |||
Logs []string | |||
// ContainerErrors - any errors that occurred while starting containers | |||
// in the pod. | |||
ContainerErrors []error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm deliberately keeping this separate from Logs, because Logs being set doesn't change exit code, and this does
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work via remote for the same reason as #8865
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
af66800
to
1a54a8b
Compare
LGTM |
In 2.2.x, we moved `play kube` to use the Start() API for pods, which reported errors in a different way (all containers are started in parallel, and then results reported as a block). The migration attempted to preserve compatibility by returning only one error, but that's not really a viable option as it can obscure the real reason that a pod is failing. Further, the code was not correctly handling the API's errors - Pod Start() will, on any container error, return a map of container ID to error populated for all container errors *and* return ErrPodPartialFail for overall error - the existing code did not handle the partial failure error and thus would never return container errors. Refactor the `play kube` API to include a set of errors for containers in each pod, so we can return all errors that occurred to the frontend and print them for the user, and correct the backend code so container errors are actually forwarded. Signed-off-by: Matthew Heon <[email protected]>
1a54a8b
to
7e3fb33
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/lgtm |
In 2.2.x, we moved
play kube
to use the Start() API for pods, which reported errors in a different way (all containers are started in parallel, and then results reported as a block). The migration attempted to preserve compatibility by returning only one error, but that's not really a viable option as it can obscure the real reason that a pod is failing. Further, the code was not correctly handling the API's errors - Pod Start() will, on any container error, return a map of container ID to error populated for all container errors and return ErrPodPartialFail for overall error - the existing code did not handle the partial failure error and thus would never return container errors.Refactor the
play kube
API to include a set of errors for containers in each pod, so we can return all errors that occurred to the frontend and print them for the user, and correct the backend code so container errors are actually forwarded.