Support pods/logs subresource streaming about k8s

[mruoss]

Released with 2.3.0

[mruoss]

Hi @elliottneilclark

Nice catch. I think it's not such a big deal. When I've implemented the mint client for the connect operation, I was focusing on podExec. Each frame you get from podExec comes with a leading byte, annotating the channel (stdout, stderr, error). That's why I'm pattern matching against that first byte in K8s.Client.Mint.Request.map_frame/1.

Obviously, the binary stream sent when connecting to pods/log is not prefixed. So I think all that's missing is something like this: def map_frame({:binary, <<msg::binary>>}), do: {:stdout, msg}.

I will try to add a test and fix this weekend.

[elliottneilclark]

So I think all that's missing is something like this:

k8s/lib/k8s/operation.ex

Line 216 in bf4100b

Keyword.take(opts, [:stdin, :stdout, :stderr, :tty, :command, :container])

I think that this needs to accept the query params that pods/log can put forward. Here's a good list for that: https://github.com/kube-rs/kube/blob/3e7f32e7b046c5428539050674e8d2404e3680d5/kube-core/src/subresource.rs#L40

[mruoss]

I see, thanks for the hint.

I've created a PR (wip). I'm still considering splitting the pods/exec and pods/log cases for the params, though. The defaults are different and the "allowed params", too...

[elliottneilclark]

I've created a PR (wip).

Thank you. I like that; it's elegant in re-using what's already there.

I'm still considering splitting the pods/exec and pods/log cases for the params, though.

That makes sense; most of the clients I could find had separate APIs for exec/connect and logging. It would also allow for a cleaner API when not trying to follow the logs (aka :get with the log subresource.)