search

vscode-kubernetes-tools / vscode-kubernetes-tools-api

A NPM package for building Kubernetes extensions for Visual Studio Code
Other
9 stars 15 forks source link

Add new Local Redirection Debugger API #31

Closed daniv-msft closed 3 years ago

daniv-msft commented 4 years ago

Please note that this PR won't be merged until the corresponding logic in vscode-kubernetes-tools is implemented.

This new API will allow other extensions to register as Local Redirection Debuggers. Such extension will provide a user interface for working with a type of debugger redirecting the traffic from the user's cluster to the local machine, rather than doing it remotely.

squillace commented 4 years ago

Tagging @lstocchi for our conversation. This is the potential hook for local debuggers.

daniv-msft commented 4 years ago

Tagging @lstocchi for our conversation. This is the potential hook for local debuggers.

@lstocchi, @itowlson Please don't hesitate to let me know if you need any other information/discussion to review this change.

lstocchi commented 4 years ago

@daniv-msft sorry for the late response, i completely forgot this, my bad. Starting to look at it now.

What's the plan on this? Is there already someone who is working on it from the k8s-tool side? @squillace

daniv-msft commented 4 years ago

@daniv-msft sorry for the late response, i completely forgot this, my bad. Starting to look at it now.

What's the plan on this? Is there already someone who is working on it from the k8s-tool side? @squillace

Thanks @lstocchi for having a look! From our discussion, @squillace and @itowlson are aligned with this change but the exact implementation (API surfaced, etc.) needs to be finalized. From purely an implementation perspective, my plan so far was that my team would drive the implementation effort.

lstocchi commented 4 years ago

Thanks @lstocchi for having a look! From our discussion, @squillace and @itowlson are aligned with this change but the exact implementation (API surfaced, etc.) needs to be finalized. From purely an implementation perspective, my plan so far was that my team would drive the implementation effort.

Thanks for the update @daniv-msft :+1: cc @gorkem

gorkem commented 4 years ago

What exactly is meant with Local Redirection Debugger?

daniv-msft commented 4 years ago

What exactly is meant with Local Redirection Debugger?

@gorkem Developers working with Kubernetes often debug their code locally (they just run it as a local service and mock/run dependencies locally) or remotely (they deploy their code changes in cluster and debug from there). As of today, the debugging options provided by the Kubernetes extension are remote debugging.

Both local and remote debugging capabilities have their advantages and drawbacks, but there is another way that offers a better solution from our perspective: redirecting the traffic from the cluster locally, and run the service to be debugged locally. This is the approach taken by Telepresence and by Bridge to Kubernetes (my team), and this is what I mean by Local Redirection Debugger.

squillace commented 4 years ago

yeah. Easier to show and explain, but basically tunneling in to dynamically reroute a "remote" cluster's service X to use the local, native (uncontained) process transparently. The idea is to give K8s devs the native F5 debug experience for the service they're working on directly integrated into the larger app of which service X is a part.

Does that make sense? My life has been totally distracted; I failed to send a meeting note. But that's the idea. Any tunneling debugger could use this hook for example, which will if none are chosen redirect to the marketplace to search for the category -- like the Cloud Provider api does.

gorkem commented 4 years ago

Ahh OK just the difference in terminology. It is what I call trampoline because it jumps to local and back.

daniv-msft commented 3 years ago

@lstocchi, @gorkem, @itowlson Could you please let me know if you would like to change anything on this PR, or if the current API proposal look good to you? Even though we don't want to check this one in immediately, we would like to be sure that the API looks good before working on the next components.

daniv-msft commented 3 years ago

@gorkem @lstocchi Apologies for the late follow up. You brought up an interesting idea during our discussion about surfacing an API to detect if the debugging could be enabled before surfacing the Debug (Local Redirection) option. I thought a bit more about this, and I'm wondering if we should leave this responsibility to the extension providing the debugging capability:

Would you have any other feedback that I didn't consider? Anything else that would create a bad user experience if we were not providing this API?

amsoedal commented 3 years ago

Hey all,

I've opened a PR with an implementation proposal for this API over on the other repo, as well as made some changes (mostly renames) to this API (also in a separate PR). Please don't hesitate to give any feedback or ideas for improvement!

daniv-msft commented 3 years ago

Closing this pull request as all the ongoing comments were addressed, and @amsoedal is taking over this work in: