Do not start pod on ssh connect

[solesensei]

Do not start pod on ssh connect

[pascalbreuninger]

@solesensei thank for opening the issue. What behaviour would you expect after terminating the pod? Connection failure?

[solesensei]

@pascalbreuninger
Yes, if you have stopped the pod, then any SSH connection should fail.

Till you explicitly start the workspace again

[solesensei]

Any updates?

[solesensei]

@pascalbreuninger I think the option would be nice at least --do-not-start-on-connection

[pascalbreuninger]

I was thinking about this proposal and to me it comes down to the foundational question of whether DevPod is expected to just create a workspace or as a tool to create and manage machines (infrastructure) and containers.
I am leaning towards on the former side, personally. This also bears the implication that DevPod always attempts to recreate the infrastructure needed to run a workspace.

We could implement the flag for sure, question is if it fits the projects "philosophy" 🤷‍♂️
What do you think?

[solesensei]

DevPod is expected to just create a workspace or as a tool to create and manage machines (infrastructure) and containers. I am leaning towards on the former side, personally.

@pascalbreuninger thanks for your answer

DevPod is already part of handling infrastructure tasks. It can make virtual machines and Kubernetes pods, and you can stop them either on your own or by setting an inactive timeout. I also don't think the tool has to solve really complex infrastructure issues.

In my opinion, the key thing DevPod should tackle is making it easier to create a consistent development environment with the resources you need. Sure, you can make your own virtual machine, connect through SSH, install Docker, and then use the devcontainer command line to start your container. But DevPod can do all of that in one go.

Talking about "recreating the infrastructure needed for a workspace," I'm fine with that. The issue is that it's surprising when connecting to your Kubernetes pod without explicitly using any devpod command.

When you run the ssh my-host command, it's basically triggering a behind-the-scenes DevPod setup. What's worse is you might not expect this, especially when working in your IDE, which might use the same command just to check the connection. Creating a workspace on Kubernetes can take 10-20 minutes, especially with heavy configurations. An engineer might not notice it, shut down their workspace, close the IDE, and unintentionally leave a running workspace for days, leading to unnecessary costs. #741

But I can understand the reasons behind the current behaviour. It's convenient to just do devpod up my-workspace and have your workspace up and running. However, for connecting via SSH, a better option could be having ProxyCommand /usr/local/bin/devpod ssh --do-not-start in my ~/.ssh/config.

[pascalbreuninger]

When you run the ssh my-host command, it's basically triggering a behind-the-scenes DevPod setup. What's worse is you might not expect this, especially when working in your IDE, which might use the same command just to check the connection. Creating a workspace on Kubernetes can take 10-20 minutes, especially with heavy configurations. An engineer might not notice it, shut down their workspace, close the IDE, and unintentionally leave a running workspace for days, leading to unnecessary costs. #741

Thanks for the explanation, I do understand your problem way better now!