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

Cannot pod.exec(...) with stdin #342

Open
JanPokorny opened this issue Mar 21, 2024 · 3 comments
Open

Cannot pod.exec(...) with stdin #342

JanPokorny opened this issue Mar 21, 2024 · 3 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@JanPokorny
Copy link

Which project are you reporting a bug for?

kr8s

What happened?

I tried using pod.exec with stdin, but got an error message AttributeError: 'AsyncWebSocketSession' object has no attribute 'protocol' from this line:

f"{ws.protocol}, only with v5.channel.k8s.io"
-- clearly that's just a typo, protocol should be subprotocol in the error message.

It seems like the only passed protocol is the v4 one (

EXEC_PROTOCOL = "v4.channel.k8s.io"
) -- which is weird, the error message seems to suggest that there's some way to switch to v5. But given the skipped test (
@pytest.mark.xfail(reason="Exec protocol v5.channel.k8s.io not available")
) I suppose there isn't?

I saw no tracking issue, so I am reporting this even though the underlying issue seems to be already known.

Anything else?

No response

@JanPokorny JanPokorny added the bug Something isn't working label Mar 21, 2024
@jacobtomlinson
Copy link
Member

I think this is sort of a duplicate of #212 so I'm going to close this out here. Currently using stdin with exec is just broken with the websockets API in Kubernetes. We need a solution to be released upstream in Kubernetes.

@JanPokorny
Copy link
Author

@jacobtomlinson Is it possible to have the "less broken" behavior in the meantime? Eg. what the official library does -- can pass stdin, but it can't be closed client-side.

I'm currently using the official library with a workaround -- closing the input server-side by piping the input through /usr/bin/sed '/\\x0/Q' and sending a null byte at the end, which works for my use case since I send only text.

@jacobtomlinson
Copy link
Member

jacobtomlinson commented Apr 4, 2024

I'd be happy to make it possible to opt into using stdin, but given that users will undoubtedly fall into the trap of trying and failing to close the stream on the client side I'd like to think of a way for users to explicitly opting into this.

I can think of a few options:

  • We raise a warning, but this may be a bit noisy.
  • We add a flag that has to be set to opt-in

PRs with a proposal would be very welcome here.

@jacobtomlinson jacobtomlinson reopened this Apr 4, 2024
@jacobtomlinson jacobtomlinson added the help wanted Extra attention is needed label Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants