What does this --keep-alive do exactly? Is it a bump or a pause or...?

I'm imagining that it just periodically sends a request to /api/v2/workspaces/:workspace/extend so that the workspace never gets turned off.

I'm imagining that it just periodically sends a request to /api/v2/workspaces/:workspace/extend so that the workspace never gets turned off.

Yes, exactly. If we had a VS Code plugin, this could be implemented there too.

I suggested something in config-ssh so we can uniformly support JetBrains, VS Code, Vim and misc. terminal work.

When does it stop sending that keep alive?

When does it stop sending that keep alive?

When the connection terminates. E.g when the computer sleeps.

Hmm. My computer never sleeps unless I'm away from home. I also don't exit VS Code.

Yeah that's a challenge. The customer in question is fine with that. The turning off is a big nice to have for them. It also still works well in multi-workspace situations. You're unlikely to keep multiple VS Codes open with multiple workspaces all the time.

You're unlikely to keep multiple VS Codes open with multiple workspaces all the time.

uh 😬

You're unlikely to keep multiple VS Codes open with multiple workspaces all the time.

uh 😬

You're an edge case of an edge case of an edge case of an edge case.

Possibly. We should gather data.

Contributing data: I'm with @ketang on this one! I love to keep all my projects/workspaces open so I can bounce between them with ease.

@ajmeese7 I agree and do the same thing.

Perhaps instead of activity detection at the SSH level we can do something more intelligent as a VS Code plugin. For example, we could bump the workspace on user-interaction.

For automatic keep alive, we'll probably want to expose a fair number of knobs and switches, primarily around which events count for liveness and how long their effects are. Given how tricky this can be to get right, I don't want to have it entirely in opaque, unparameterizable code.

What MVP can we start with?

Incrementally replicate v1 but expose the knobs and switches.

Incrementally replicate v1 but expose the knobs and switches.

What does "replicate v1" mean? Why do you think we need to expose the knobs right now? Which knobs do you think we should expose?

I was kind of waving my hands because I haven't actually looked at the v1 implemention. But presumably it's basically some set of event types that count as activity and some grace period after each occurrence during which shutdown is deferred. What we could do is just expose a map from event type to grace period. We'd have sensible defaults that they could override, either by adding an event type, adjusting the grace period for an event type, or excluding an event type.

Relying on a CLI command parameter setting is limited and flawed.

The customers, except for 1, use Coder completely browser-based, so some semblance of idle detection is not met with the CLI configuration.

To be clear, the largest of these customers actually does NOT like the existing idle behavior of v1. Their desired state is if the auto-shutdown behavior set by admins is 4 hours, then in 4 hours, if nothing was going on in the IDE or terminal, the workspace (in this case, a Kubernetes pod, is destroyed)

So their desired state is not met by v1 either.

@ammario @ketang @johnstcn

Ah I didn't mean that it would be in the CLI. It would be server-side.

I think giving customers control is the only realistic option. We don't know how do it perfectly, and giving them more control is a good compromise until we figure it out.

It looks certain we're going to do this. Let's discuss implementation in #2995.