Ctrl-C doesn't work during 'odo dev' build phase and if build is stuck the only way out is killing the terminal

[dgolovin]

/kind bug

What versions of software are you using?

Operating System: Linux

Output of odo version: 3.0.0-rc1

How did you run odo exactly?

odo dev for project created with nodejs-angular devfile and starter project
make install command never exit by adding && npm run dev

Actual behavior

Command shows
Building your application in container on cluster (command: install) ...
and no reaction to Ctrl - C

The same behavior is for long build like java devfiles

/  \__     Developing using the java-maven-development Devfile
\__/  \    Namespace: nivologd-dev
/  \__/    odo version: v3.0.0-rc1
\__/

↪ Deploying to the cluster in developer mode
•  Waiting for Kubernetes resources  ...
✓  Added storage m2 to component
⚠  Pod is Pending
✓  Pod is Running
•  Syncing files into the container  ...
✓  Syncing files into the container [1s]
•  Building your application in container on cluster (command: mvn-package)  ...
^C
✓  Building your application in container on cluster (command: mvn-package) [28s]
•  Executing the application (command: run)  ...
-  Forwarding from 127.0.0.1:40001 -> 8080


Watching for changes in the current directory /home/denis/temp/demo1
Press Ctrl+c to exit `odo dev` and delete resources from the cluster

✗  Dev mode interrupted by user
Cleaning resources, please wait
✗  Finished executing the application (command: run) [41s]

If build is long enough and user exits by closing terminal it leaves the cluster with 'inner loop resources' for the component.

Expected behavior

Ctrl - C works at every phase of the 'odo dev'

Any logs, error output, etc?

See above

[valaparthvi]

We needed a way to stop the execution of long running processes such as file sync and command execution if Ctrl+C is encountered. After some debugging we came across ExecCmdInContainer which is responsible for all the communications between local system and container, and this is where we need to catch Ctrl+C signal.

// "k8s.io/client-go/tools/remotecommand"


// ExecCMDInContainer execute command in the container of a pod, pass an empty string for containerName to execute in the first container of the pod
func (c *Client) ExecCMDInContainer(containerName, podName string, cmd []string, stdout io.Writer, stderr io.Writer, stdin io.Reader, tty bool) error {

	---Omitted for brevity---

	// Connect to url (constructed from req) using SPDY (HTTP/2) protocol which allows bidirectional streams.
	exec, err := remotecommand.NewSPDYExecutor(config, "POST", req.URL())
	if err != nil {
		return fmt.Errorf("unable execute command via SPDY: %w", err)
	}
	// initialize the transport of the standard shell streams
	err = exec.Stream(remotecommand.StreamOptions{
		Stdin:  stdin,
		Stdout: stdout,
		Stderr: stderr,
		Tty:    tty,
	})
	if err != nil {
		return fmt.Errorf("error while streaming command: %w", err)
	}

	return nil
}

This method uses k8s/client-go to start a stream and closes it only when client closes the connection or the server disconnects. The current library version does not have a way to interpret signals, but the new version(~28 days old) does with kubernetes/kubernetes#103177. A new method StreamWithContext replaces the Stream method which is now marked deprecated.

Updating the library should ideally fix the problem for us, but there's one more catch. We also use openshift/client-go library in odo, which requires to use a certain version of k8s.io/client-go.
If openshift/client-go updates their k8s.io/client-go, we should be able to use the new method, optimistically fixing the issue at hand.

We'll wait on fixing this until we can update the library.

[feloy]

Make some research to check if openshift client-go library includes the PR kubernetes/kubernetes#103177

[feloy]

Also check on podman if it is the same blocking part.

[kadel]

Make some research to check if openshift client-go library includes the PR kubernetes/kubernetes#103177

this might be a good opportunity to get rid of the openshift-specific code and use only Kubernetes libraries. We should be able to do everything with just k8s libs

[feloy]

This part of the code is using the Kubernetes libraries. The exec.StreamWithContext will be available with PR #6602

[valaparthvi]

Removing status/blocked since the required method is now available and we can make another attempt at fixing this.