Yes its will be great to support exec and attach to container from the client-go.
I really need it.

I agree, we should support these.

Until the work on this ticket is done, it is pretty simple to use ther rest.Config to create your own exec call. I created a simple example. A detailed description is also available.

@rmohr thanks for the simple example.
The only problem with your example is that you can't detect if the command return with a non zero exit code.

I need this enough to pick it up and work on a PR.

Seems like kubectl would also benefit from this

Going to make an effort at adding client support for an Exec() method (not sure where it should live) which allows different Executors, and has a default one like this.

Thoughts? Suggestions? Cryptic warnings?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

What's the update on this?

So should we reopen this issue?

I'll be happy to work on this, If provided some initial pointers. The current way to do this seems to be using websockets only. right?

/reopen

@LeoLiuYan: You can't reopen an issue/PR unless you authored it or you are a collaborator.