Registry devfiles are incompatible with odo dev --debug

[jeffmaury]

/kind bug

What versions of software are you using?

Operating System: Win10Pro

Output of odo version:

C:\work\src\tmp\nodejs-ex>odo version
odo v3.0.0-beta2 (c8e4458f4)

Server: https://api.sandbox-m2.ll9k.p1.openshiftapps.com:6443
Kubernetes: v1.23.5+9ce5071

How did you run odo exactly?

odo dev --debug

Actual behavior

The debug port should be forwarded as well

Expected behavior

Only the application port is forwarded

Any logs, error output, etc?

[dgolovin]

@jeffmaury even if it forwarded it is not clear how to distinguish application ports from one should be used to connect debugger.

[jeffmaury]

Plan is to have kind information in odo describe

[rm3l]

As discussed with the team:

• An issue will need to be created on the Devfile side, with a proposal about explicitly declaring debug endpoints in Registry Devfiles
  • The proposal would include a naming convention for such debug endpoint, so it can be identified by tools like odo
• Once the proposal is accepted, then on the odo side, we would need to update the output of odo describe component (both human-readable and JSON) to include such information

[valaparthvi]

AI:

• Add DEBUG endpoint in the devfile stack for all the devfiles(https://github.com/devfile/registry) that support debugging.
• All the debugging port names should start with prefix DEBUG_.
• We need to make it clear to the user that any debug port added must be prefixed with DEBUG_, in the docs(https://devfile.io/docs/2.1.0/devfile-schema#components-container-endpoints) .
• odo describe component will have a separate section(human readable, and JSON) for debug ports.

[rm3l]

We can start working on adding debug endpoints in the Devfile registry stacks (PR to create in the Devfile registry repo). So I've added this to the v3 board.

#6036 will be addressed after v3 GA.

[rm3l]

As discussed with @kadel, there is a limitation on the endpoint name: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$. So we cannot use uppercase characters or underscores (_).

Convention for Debug endpoints would then be to have:

• either a single endpoint named debug
• or any endpoint with a name starting with debug-

[rm3l]

As discussed in the last community call, exposure for such debug endpoint will be set to none; this is what Che does, and it makes sense from the security perspective. And odo dev is trying to emulate a local developer machine.

Doing so however requires updating odo to no longer ignore endpoints with 'exposure: none': scope of #6119

I've just created a PR on the Devfile registry side to add such debug endpoints: https://github.com/devfile/registry/pull/122

I'll close this issue once https://github.com/devfile/registry/pull/122 is merged.

[rm3l]

/status blocked

Blocked until https://github.com/devfile/registry/pull/122 is merged and available in the default registry.

[rm3l]

https://github.com/devfile/registry/pull/122 has been merged on the Devfile registry side. And it looks like it is also available in both staging and production registries.

I just tested it against the default production Devfile registry, and both the application and debug ports are being forwarded:

$ odo init --name odo-debug-endpoint-test --devfile java-springboot --devfile-registry DefaultDevfileRegistry --starter springbootproject
$ odo dev --debug

...
 •  Executing the application (command: debug)  ...
 -  Forwarding from 127.0.0.1:40001 -> 8080

 -  Forwarding from 127.0.0.1:40002 -> 5858

$ jdb -attach localhost:40002
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> threadgroups
1. (java.lang.ThreadGroup)5173 system
2. (java.lang.ThreadGroup)5177 main
3. (java.lang.ThreadGroup)5178 InnocuousThreadGroup
> 

/remove-status blocked

Closing this issue as complete then.

/close

Next related steps for us:

• Ability for odo describe component to detect and show information about debug ports: https://github.com/redhat-developer/odo/issues/6036
• https://github.com/redhat-developer/odo/issues/6254

But those issues do not prevent registry Devfiles from being used with odo dev --debug.

[openshift-ci[bot]]

@rm3l: Closing this issue.

In response to this:

https://github.com/devfile/registry/pull/122 has been merged on the Devfile registry side. And it looks like it is also available in both staging and production registries.

I just tested it against the default production Devfile registry, and both the application and debug ports are being forwarded:

$ odo init --name odo-debug-endpoint-test --devfile java-springboot --devfile-registry DefaultDevfileRegistry --starter springbootproject
$ odo dev --debug

...
•  Executing the application (command: debug)  ...
-  Forwarding from 127.0.0.1:40001 -> 8080

-  Forwarding from 127.0.0.1:40002 -> 5858

$ jdb -attach localhost:40002
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> threadgroups
1. (java.lang.ThreadGroup)5173 system
2. (java.lang.ThreadGroup)5177 main
3. (java.lang.ThreadGroup)5178 InnocuousThreadGroup
> 

/remove-status blocked

Closing this issue as complete then.

/close

Next related steps for us:

• Ability for odo describe component to detect and show information about debug ports: https://github.com/redhat-developer/odo/issues/6036
• https://github.com/redhat-developer/odo/issues/6254

But those issues do not prevent registry Devfiles from being used with odo dev --debug.

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.