Our team's developers need to access their local USB devices in their Coder workspaces via USB/IP, and to minimize the latency between a USB/IP server running on a developer's local machine (which serves the USB hardware they have connected to their machine) and the USB/IP client running in a Coder workspace (which attaches that USB hardware remotely over the network),we'd like our developers to be able to provision Coder workspaces to run on their local machines (e.g. using theDocker Terraform provider).

I was describing this use case to@kylecarbs on Slack, and he mentioned:

Coder v2 has the concept of a provisioner daemon. It accepts provision operations (like workspace start/stop) and performs them. Developers could run a provisioner daemon on their local machine, and then Terraform would execute against it. This would enable Terraform to run locally, so you could useunix:///var/run/docker.sock. Our architecture certainly enables this.

We'll have to work with y'all to get the UX nice, but we can certainly provide a flow like:

1. Download the Coder CLI.
2. Run "coder provisioner" in the background.
3. Have the workspace provisioned on your local machine, using that provisioner daemon.

We'll have to add some targeting to provisionerd, but that should be simple enough!

That sounds exactly like what we were hoping for, so I've created this GitHub issue to formally request this feature in Coder. 😃

Building on what@kylecarbs suggested above, I think enabling something like the following would meet our requirements:

1. A developer can run a Coder CLI command (e.g.coder provisioner) to launch a local provisioner that is associated/authenticated with coderd using the credentials/URL the developer previously provided viacoder login.
2. A developer can specify that workspace operations (e.g. creation, stopping, etc.) should use a particular provisioner daemon so that they can ensure that a workspace will be created/provisioned/stopped on their local machine as opposed to other machines that would not immediately have the ability to provision/control Terraform resources on the developer's local machine.
   • For the CLI, maybe this could be specified via an option when runningcoder workspace create like--provisioner-daemon <PROVISIONER_DAEMON_ID> where a developer specifies the name/reference to the provisioner daemon of interest via<PROVISIONER_DAEMON_ID>?
   • For the web UI, maybe this could be a drop-down on the workspace creation webpage from which the user could select a provisioner daemon from a list of provisioner daemons that they are authorized to use (see below)?
3. A developer can restrict other Coder users from creating workspaces using a provisioner daemon they are running on their local machine. I think this would help prevent one developer from accidentally (or perhaps maliciously) creating a workspace on a different developer's machine as well as avoid having too many options for selecting a provisioner daemon in the new workspace creation web UI (see above about the proposed drop-down option) when many developers maintain their own provisioner daemons.
   • I think something that would work well for our team would be if the default behavior of Coder would be to give a developer the ability to create workspaces using a provisioner daemon they've spawned themselves but restrict other users from utilizing it unless the provisioner daemon has been associated/registered to be shared throughout a Coder organization. And maybe that association/registration could be performed by the developer via a CLI command or web UI page?

What do you think?

cc@sunilvenkatraman