microsoft / mindaro

Bridge to Kubernetes - for Visual Studio and Visual Studio Code
MIT License
307 stars 106 forks source link

Having multiple bridge-to-kubernetes tasks with different labels doesn't stop the redirection containers after stopping debug session #279

Open AlexGoris-KasparSolutions opened 2 years ago

AlexGoris-KasparSolutions commented 2 years ago

Describe the bug I have a scenario in which I want to debug multiple kubernetes workloads/services from a single folder using a single VSCode instance. To achieve this I made multiple tasks with distinct labels, like so:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "bridge-to-kubernetes.resource.handlers",
      "type": "bridge-to-kubernetes.resource",
      "resource": "invoicing-handlers-",
      "resourceType": "pod",
      "ports": [0],
      "targetCluster": "my-cluster",
      "targetNamespace": "dev",
      "useKubernetesServiceEnvironmentVariables": false
    },
    {
      "label": "bridge-to-kubernetes.resource.api-grpc",
      "type": "bridge-to-kubernetes.resource",
      "resource": "invoicing-api-grpc",
      "resourceType": "service",
      "ports": [8302],
      "targetCluster": "my-cluster",
      "targetNamespace": "dev",
      "useKubernetesServiceEnvironmentVariables": false
    }
  ]
}

As you can see I replaced the default bridge-to-kubernetes.resource label with bridge-to-kubernetes.resource.<suffix> where the suffix identifies the service or pod I want to debug. In the launch configuration, I have 2 debug configurations which point to the corresponding task, I can then launch 2 debug sessions, which will in turn set up 2 bridge-to-kubernetes tunnels, everything works fine. However, when I stop any or both of the debug sessions, the bridge-to-kubernetes tunnels won't be automatically canceled. This is not good because I'll forgot to stop the tunnels manually and our kubernetes environment will be left defunct.

To Reproduce

  1. Create debug/task configurations as described above
  2. Start one or both the debug configurations
  3. Stop one or both of the debug sessions
  4. bridge-to-kubernetes tunnels will be left intact, but since the debug session is stopped, kubernetes environment is left defunct

Expected behavior At step 3 in the steps to reproduce section, I would expect the tunnal that corresponds to the stopped debug session to be stopped as well, leaving the kubernetes cluster operational for other users.

Logs Would rather not attach logs as these contain potentially sensitive information. If needed I will clean them up and attach them.

Environment Details Client used (VS Code): mindaro.mindaro Client's version: 1.0.120220125 Operating System: Windows 11 21H2

pragyamehta commented 2 years ago

Hi @AlexGoris-KasparSolutions Can you share if the below setting in your VSCode is enabled or disabled? image

AlexGoris-KasparSolutions commented 2 years ago

@pragyamehta yes this setting is enabled. This also works fine if I debug just 1 single service/pod, it's only when I try to debug 2 services simultaneously that this happens. I have the impression the extensions is having trouble tracking the 2 bridge sessions