Exec writingErrorChannel is not an error channel

[speedfl]

Is your enhancement related to a problem? Please describe

When executing a command in a container, a io.fabric8.kubernetes.api.model.Status is sent (whatever the status, success or failure)

Here is an example on the Kubernetes-client from kubernetes team:
https://github.com/kubernetes-client/java/blob/ae3bb03f8f0a5a3915941506eec4c667785b6e0d/util/src/main/java/io/kubernetes/client/Exec.java#L495

If the command execution failed the Status will like:

apiVersion: "v1"
kind: "Status"
details: 
  causes: 
    - reason: ExitCode
      message: "128"

They then parse the status code: https://github.com/kubernetes-client/java/blob/ae3bb03f8f0a5a3915941506eec4c667785b6e0d/util/src/main/java/io/kubernetes/client/Exec.java#L444

If the command was successfully executed it will be like this:

apiVersion: "v1"
kind: "Status"
details: 
  status: "Success"

This status is always sent.

In fabric8 this streamID 3 is considered as en errorChannel (which seems not correct):
https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/internal/ExecWebSocketListener.java#L247

Here is an example of usage:

 client.pods()
        .inNamespace("test")
        .withName("name")
        .inContainer("container")
        .writingErrorChannel(endOutputStream)
        .usingListener(mylisterner)
        .exec(command);

Describe the solution you'd like

Just renaming writingErrorChannel to writingCloseChannel

Describe alternatives you've considered

No response

Additional context

No response

[manusa]

Was this fixed by #3813? @shawkins

[shawkins]

No, this is a request to rename writingErrorChannel to writingCloseChannel. In the other java client they refer to it as Exec.getConnectionErrorStream. The python client calls it error-channel https://github.com/kubernetes-client/python/blob/cc9ae10549db26dd1391de55f0da2f4946de4ad7/stream/ws_client.py#L36 - so there's little consistency.

This probably could be addressed with better javadocs on getErrorChannel and related methods.

[shawkins]

Adding better javadocs with #4115