odo dev --debug

[feloy]

What type of PR is this:

/kind feature

What does this PR do / why we need it:

Which issue(s) this PR fixes:

Fixes #5583

PR acceptance criteria:

• Unit test

• Integration test

• Documentation

How to test changes / Special notes to the reviewer:

[netlify]

✅ Deploy Preview for odo-docusaurus-preview canceled.

Name	Link
🔨 Latest commit	e755f6b
🔍 Latest deploy log	https://app.netlify.com/sites/odo-docusaurus-preview/deploys/6267d4eed9a58d0008829422

[odo-robot]

Unit Tests on commit a372b9e finished successfully.
View logs: TXT HTML

[odo-robot]

Windows Tests (OCP) on commit a372b9e finished successfully.
View logs: TXT HTML

[odo-robot]

Kubernetes Tests on commit a372b9e finished successfully.
View logs: TXT HTML

[odo-robot]

OpenShift Tests on commit a372b9e finished successfully.
View logs: TXT HTML

[odo-robot]

Validate Tests on commit a372b9e finished successfully.
View logs: TXT HTML

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[dharmit]

@feloy in the past when we were working on debug mode, we used to consider testing things using VS Code launch.json and connecting to the port on which the app's debug mode port is listening.

For this PR, I downloaded the devfile in the tests of this PR, but can't really connect to it. Or, maybe, VS Code is connecting to it, but I don't know what to do. Also, I have never worked with websockets myself, so maybe I'm doing it completely wrong.

Do you think you can share the steps you followed to test the debug mode yourself?

I spent some time on it, but still feel dumb about this thing (how to test debug mode functionality.)

[feloy]

@feloy in the past when we were working on debug mode, we used to consider testing things using VS Code launch.json and connecting to the port on which the app's debug mode port is listening.

For this PR, I downloaded the devfile in the tests of this PR, but can't really connect to it. Or, maybe, VS Code is connecting to it, but I don't know what to do. Also, I have never worked with websockets myself, so maybe I'm doing it completely wrong.

Do you think you can share the steps you followed to test the debug mode yourself?

I spent some time on it, but still feel dumb about this thing (how to test debug mode functionality.)

@dharmit It should be the exact same way as with odo v2. If you follow the steps described in this blog post (Debugging the micro-service), it should work: https://dev.to/feloy/odo-a-tool-to-simplify-development-on-kubernetes-5c9a

To test with the files used in the integration test, you can get the launch.json from the blog post, then run a Debug session and set a Breakpoint where a request is replied (on the res.send('Hello from Node.js Starter Application!'); for example). Then you execute a request on your app endpoint (curl 127.0.0.1:40001) and vscode should pop up and show your program interrupted on your breakpoint

[rm3l]

@feloy in the past when we were working on debug mode, we used to consider testing things using VS Code launch.json and connecting to the port on which the app's debug mode port is listening.

For this PR, I downloaded the devfile in the tests of this PR, but can't really connect to it. Or, maybe, VS Code is connecting to it, but I don't know what to do. Also, I have never worked with websockets myself, so maybe I'm doing it completely wrong.

Do you think you can share the steps you followed to test the debug mode yourself?

I spent some time on it, but still feel dumb about this thing (how to test debug mode functionality.)

FWIW, I tested this PR earlier today using this sample Spring-Boot Maven project (forked from the SpringBoot Getting Started Guides to add a devfile.yaml). Then used jdb (but we can use IDEs like IntelliJ IDEA) to connect to the local port:

❯ git clone https://github.com/rm3l/gs-spring-boot
❯ cd gs-spring-boot/complete
❯ odo dev --debug

# In a separate terminal
❯ jdb -attach localhost:40002
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...

> threads
Group system:
  (java.lang.ref.Reference$ReferenceHandler)6377                       Reference Handler      running
  (java.lang.ref.Finalizer$FinalizerThread)6378                        Finalizer              cond. waiting
  (java.lang.Thread)6379                                               Signal Dispatcher      running
Group main:
  (org.apache.tomcat.util.threads.TaskThread)6382                      Catalina-utility-1     cond. waiting
  (org.apache.tomcat.util.threads.TaskThread)6383                      Catalina-utility-2     cond. waiting
  (org.springframework.boot.web.embedded.tomcat.TomcatWebServer$1)6384 container-0            sleeping
  (java.lang.Thread)6385                                               http-nio-8080-Poller   running
  (java.lang.Thread)6386                                               http-nio-8080-Acceptor running
  (java.lang.Thread)6387                                               DestroyJavaVM          running
Group InnocuousThreadGroup:
  (jdk.internal.misc.InnocuousThread)6388                              Common-Cleaner         cond. waiting

> stop at com.example.springboot.HelloController:11
Set breakpoint com.example.springboot.HelloController:11

### Then running 'curl http://localhost:40001/' in a separate terminal should hit the breakpoint set:
Breakpoint hit: "thread=http-nio-8080-exec-3", com.example.springboot.HelloController.index(), line=11 bci=0

http-nio-8080-exec-3[1] list
Source file not found: HelloController.java

http-nio-8080-exec-3[1] where
  [1] com.example.springboot.HelloController.index (HelloController.java:11)                                                                                                                                                                   
  [2] jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (native method)                                                                                                                                                                    
  [3] jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)                                                                                                                                                  
  [4] jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)                                                                                                                                          
  [5] java.lang.reflect.Method.invoke (Method.java:566)                                                                                                                                                                                        
  [6] org.springframework.web.method.support.InvocableHandlerMethod.doInvoke (InvocableHandlerMethod.java:205)                                                                                                                                 
--- TRUNCATED ---

http-nio-8080-exec-3[1] cont
> 

[dharmit]

To test with the files used in the integration test, you can get the launch.json from the blog post, then run a Debug session and set a Breakpoint where a request is replied (on the res.send('Hello from Node.js Starter Application!'); for example). Then you execute a request on your app endpoint (curl 127.0.0.1:40001) and vscode should pop up and show your program interrupted on your breakpoint

@feloy I am doing something wrong, it seems.

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "attach",
            "name": "odo dev debug",
            "program": "${workspaceFolder}/server.js",
            "address": "localhost",
            "port": 40002,
            "localRoot": "${workspaceFolder}",
        }
    ]
}

I have added breakpoints at both the lines in the server.js that have Hello from Node.js in them. I run odo dev --debug, then I start debugging session from VS Code, and finally do curl localhost:40001/curl localhost:40002. Neither of them takes me to the breakpoint.

The feeling of dumbness is getting real bad at this point, so I'll approve since I don't want my limitation to block your PR.

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dharmit

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dharmit]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[feloy]

To test with the files used in the integration test, you can get the launch.json from the blog post, then run a Debug session and set a Breakpoint where a request is replied (on the res.send('Hello from Node.js Starter Application!'); for example). Then you execute a request on your app endpoint (curl 127.0.0.1:40001) and vscode should pop up and show your program interrupted on your breakpoint

@feloy I am doing something wrong, it seems.

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "attach",
            "name": "odo dev debug",
            "program": "${workspaceFolder}/server.js",
            "address": "localhost",
            "port": 40002,
            "localRoot": "${workspaceFolder}",
        }
    ]
}

I have added breakpoints at both the lines in the server.js that have Hello from Node.js in them. I run odo dev --debug, then I start debugging session from VS Code, and finally do curl localhost:40001/curl localhost:40002. Neither of them takes me to the breakpoint.

The feeling of dumbness is getting real bad at this point, so I'll approve since I don't want my limitation to block your PR.

/approve /lgtm

Can you try with this launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to remote 5858",
            "type": "node",
            "request": "attach",
            "address": "localhost",
            "port": 40002,
            "localRoot": "${workspaceFolder}",
            "remoteRoot": "/projects"
        }
    ]
}

[feloy]

/override ci/prow/v4.10-integration-e2e

IBM Could tests pass

[openshift-ci]

@feloy: Overrode contexts on behalf of feloy: ci/prow/v4.10-integration-e2e

In response to this:

/override ci/prow/v4.10-integration-e2e

IBM Could tests pass

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dharmit]

Can you try with this launch.json:

That works. Thanks!

It works when I curl the port 40001, not 40002. However, the debug port 5858 is forwarded to 40002:

Your application is now running on the cluster
 - Forwarding from 127.0.0.1:40001 -> 3000
 - Forwarding from 127.0.0.1:40002 -> 5858

I think I need to use websockets instead of http when trying to work with 40002, right?

[feloy]

Port 5858 (and 40002) are for the debugger only, for it to be able to communicate with the process inside the container. You, as a developer, don't need to use it directly.

[dharmit]

OK, thanks for guiding me patiently. I surely need some debugging 101 class/course. 😞