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

ExecWithOption - get rid of stdout/stderr buffers #2506

Merged
merged 4 commits into from
Jan 4, 2024

Conversation

e-sumin
Copy link
Contributor

@e-sumin e-sumin commented Dec 1, 2023

Change Overview

Invoker of kube.ExecWithOptions has the possibility to get the stdout/stderr streams by passing appropriate io.Writers via ExecOptions. Since all its invokers do this, it's redundant to collect the same streams into internal buffers and return them as a string.

At the same time, we have kube.Exec which is simplified version of kube.ExecWithOptions. This kube.Exec is the only case when we need to collect stdout/stderr to a buffer and return them after execution is done.

Therefore, let's move this buffering to kube.Exec and simplify kube.ExecWithOptions

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

Test Plan

  • 💪 Manual
  • ⚡ Unit test
  • 💚 E2E

@infraq infraq added this to In Progress in Kanister Dec 1, 2023
@e-sumin e-sumin changed the base branch from master to common-exec-error-handling December 1, 2023 09:53
@e-sumin e-sumin requested a review from hairyhum December 4, 2023 10:33
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.

The change makes sense.
@pavannd1 @viveksinghggits but I wonder if we have any process (e.g. versioning) to notify the user of public API changes?

Base automatically changed from common-exec-error-handling to master December 13, 2023 11:24
func ExecWithOptions(kubeCli kubernetes.Interface, options ExecOptions) (string, string, error) {
// ExecWithOptions executes a command in the specified container, returning an error.
// `options` allowed for additional parameters to be passed.
func ExecWithOptions(kubeCli kubernetes.Interface, options ExecOptions) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

After looking at the desc, I thought, are there use cases where some consumers would need Exec and others would need ExecWithOptions, can we not just expose one. So that it's easier to use these APIs?

Copy link
Contributor

Choose a reason for hiding this comment

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

LGTM otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the ideal case, of course, it would be better to use ExecWithOptions only. But, unfortunately, both are widely used.

Looking on the code, I figured out that ExecOutput is probably even more redundant.

I can do bigger refactoring and reduce number of execs, but it will be bigger change, so maybe we can do that by two or three steps ? This one, drops buffering in ExecWithOptions, Second one will remove ExecOutput and, if we will agree, that we'd like to do that, the third (and the biggest one) can get rid of pure Exec ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Now, that I think about it again, I don't think we should block the PR in this discussion. I think names are sufficient enough to not cause any confusion.
If we want to exec with some options use ExecWithOptions otherwise use Exec.

Copy link
Contributor

@PrasadG193 PrasadG193 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 15, 2023
@e-sumin e-sumin added the kueue label Jan 4, 2024
@mergify mergify bot merged commit a5a722f into master Jan 4, 2024
15 checks passed
Kanister automation moved this from Reviewer approved to Done Jan 4, 2024
@mergify mergify bot deleted the exec-get-rid-of-buffer branch January 4, 2024 17:03
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.

None yet

4 participants