Cannot run and attach a new pod that needs standard input

[DavidPerezIngeniero]

Describe the bug

I'm experimenting with the library with my use case of starting a pod and providing it input.

Fabric8 Kubernetes Client version

6.2.0

Steps to reproduce

cli = new KubernetesClientBuilder().build();
pod = cli.run().withRunConfig(new RunConfigBuilder().withCommand("cat").withRestartPolicy("Never").withName("cucu").withImage("alpine").build()).done();
pr = cli.pods().withName("cucu") ;
a = pr.attach();  <==== it crashes
a.getInput().write("Hello".getBytes());

Expected behavior

I start a pod which executes cat.
I want to provide standard input to the pod.
So I attach, right away after having started the pod.
After attaching, I'd like to use readInput() in order to send data.
But the pod finishes, before I have a chance to provide input.

Runtime

minikube

Kubernetes API Server version

1.24

Environment

Linux

Fabric8 Kubernetes Client Logs

io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
  io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:129)
  io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:122)
  io.fabric8.kubernetes.client.utils.Utils.waitUntilReady(Utils.java:174)
  io.fabric8.kubernetes.client.utils.Utils.waitUntilReadyOrFail(Utils.java:184)
  io.fabric8.kubernetes.client.dsl.internal.core.v1.PodOperationsImpl.setupConnectionToPod(PodOperationsImpl.java:321)
  io.fabric8.kubernetes.client.dsl.internal.core.v1.PodOperationsImpl.attach(PodOperationsImpl.java:286)
  ammonite.$sess.cmd9$.<clinit>(cmd9.sc:1)
io.fabric8.kubernetes.client.http.WebSocketHandshakeException
  io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl$BuilderImpl$1.onFailure(OkHttpWebSocketImpl.java:72)
  okhttp3.internal.ws.RealWebSocket.failWebSocket(RealWebSocket.java:571)
  okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:198)
  okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
  okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  java.lang.Thread.run(Thread.java:833)
java.net.ProtocolException: Expected HTTP 101 response but was '400 Bad Request'

Additional context

Related documentation:

https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-examples/src/main/java/io/fabric8/kubernetes/examples/kubectl/equivalents/PodRunEquivalent.java

https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-examples/src/main/java/io/fabric8/kubernetes/examples/kubectl/equivalents/PodAttachEquivalent.java

By the way, it would be interesting to obtain directly a PodResource, given a Pod.

[shawkins]

a = pr.attach(); <==== it crashes

Does the pod have multiple containers? Until #4505 you have to set one if there are multiple.

By the way, it would be interesting to obtain directly a PodResource, given a Pod.

For 6+ there is a resource(KuberenetesResource) method available at KubernetesClient.resource that provides a Resource, and client.pods().resource will provide a PodResource.

[DavidPerezIngeniero]

Thanks for the answer.
A single container per pod. I'm beginning with simple use cases.

Workaround is invoking directly kubectl run -i, instead of using fabric8 library.

The metohd client.pods().resource() is exactly what I was looking for.

[shawkins]

Workaround is invoking directly kubectl run -i, instead of using fabric8 library.

@DavidPerezIngeniero since it's not multiple containers, I believe the issue is that you have to declare usage of either some input or output - otherwise kube will reject as a bad request. So try pr.redirectingInput().attach() instead.

We should probably add a better message in this case since one doesn't seem to be coming from the api server.

[DavidPerezIngeniero]

After trying your valuable suggestion:

a = pr.redirectingInput().attach() 
io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
  io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:129)
  io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:122)
  io.fabric8.kubernetes.client.utils.Utils.waitUntilReady(Utils.java:174)
  io.fabric8.kubernetes.client.utils.Utils.waitUntilReadyOrFail(Utils.java:184)
  io.fabric8.kubernetes.client.dsl.internal.core.v1.PodOperationsImpl.setupConnectionToPod(PodOperationsImpl.java:321)
  io.fabric8.kubernetes.client.dsl.internal.core.v1.PodOperationsImpl.attach(PodOperationsImpl.java:286)
  ammonite.$sess.cmd8$.<clinit>(cmd8.sc:1)
io.fabric8.kubernetes.client.http.WebSocketHandshakeException
  io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl$BuilderImpl$1.onFailure(OkHttpWebSocketImpl.java:72)
  okhttp3.internal.ws.RealWebSocket.failWebSocket(RealWebSocket.java:571)
  okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:198)
  okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
  okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  java.lang.Thread.run(Thread.java:833)
java.net.ProtocolException: Expected HTTP 101 response but was '500 Internal Server Error'

kubectl logs cucu

shows no logs.

[shawkins]

@DavidPerezIngeniero looking at the PodIT test case what it is doing differently is waiting for the pod to be ready before attempting an attach:

client.pods().withName("cucu").waitUntilReady(10, TimeUnit.SECONDS);

I'm not sure why that isn't baked into the attach / exec operations - it is for watching logs.

[manusa]

I'm not sure why that isn't baked into the attach / exec operations - it is for watching logs.

So are you suggesting to perform this check before the actual exec/attach operation?

That would improve the UX, but I'm not sure if we might want to make it as an opt-in behavior

[shawkins]

That would improve the UX, but I'm not sure if we might want to make it as an opt-in behavior

Looking at the log behavior, it waits 5 seconds by default, but can be overriden by withLogWaitTimeout - seems like we could generalize that to readyTimeout and make it applicable to attach / exec.