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

Common exec error handling #2501

Merged
merged 5 commits into from
Dec 13, 2023
Merged

Common exec error handling #2501

merged 5 commits into from
Dec 13, 2023

Conversation

e-sumin
Copy link
Contributor

@e-sumin e-sumin commented Nov 30, 2023

Change Overview

This PR contains fix for #2066
From now, regardless the way of invocation, execution error will contain tail of stdout/stderr.
Which then could be used by the invoker to construct more precise error.

Pull request type

Please check the type of change your PR introduces:

  • 🚧 Work in Progress
  • 🌈 Refactoring (no functional changes, no api changes)
  • 🐹 Trivial/Minor
  • 🐛 Bugfix
  • 🌻 Feature
  • 🗺️ Documentation
  • 🤖 Test

Issues

Test Plan

  • 💪 Manual
  • ⚡ Unit test
  • 💚 E2E

@infraq infraq added this to In Progress in Kanister Nov 30, 2023
tty)

if err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is that necessary here?
It seems like this will change the behaviour for ExecWithOptions so it always returns error, should it be left in pod_command_executor?
Am I missing something here?

Copy link
Contributor Author

@e-sumin e-sumin Dec 4, 2023

Choose a reason for hiding this comment

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

Old code was returning error (or nil) as is, new code returns nil as is, and wraps an error with ExecError (which contains stderr/stdout tails), what is actually was the purpose of this PR.

Because without that change, only PodCommandExecutor users were able to find/parse an error in logs, and we want to give this possibility for users of kube.Exec/kube.ExecWithOptions/kube.ExecOutput too.

Copy link
Contributor

@hairyhum hairyhum left a comment

Choose a reason for hiding this comment

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

LGTM

Kanister automation moved this from In Progress to Reviewer approved Dec 4, 2023
@viveksinghggits
Copy link
Contributor

LGTM, we can merge after Prasad looks into the reply of his comment.

@e-sumin e-sumin added the kueue label Dec 13, 2023
@mergify mergify bot merged commit f435763 into master Dec 13, 2023
14 checks passed
Kanister automation moved this from Reviewer approved to Done Dec 13, 2023
@mergify mergify bot deleted the common-exec-error-handling branch December 13, 2023 11:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging this pull request may close these issues.

kube.Exec and podCommandExecutor.Exec should create the ExecOptions similarly
4 participants