Skip to content

Ensure the workspace agent can reuse its existing token when required #364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
SasSwart opened this issue Mar 17, 2025 · 0 comments
Open
Assignees

Comments

@SasSwart
Copy link
Contributor

SasSwart commented Mar 17, 2025

In coderd, when we provision a prebuild, we start a normal running workspace. This workspace has an agent running on it, and the design of prebuilds relies on neither the workspace nor the agent having to restart when the prebuild is claimed (if they restart, this obviates the prebuild because the start time can be very slow).

When a workspace has a coder_agent defined in its template, this agent resource will be created in the workspace_agents table upon terraform apply. All other template collateral, including the VM/container/whatever on which the agent runs, will be recorded in the workspace_resources table. The agent has an FK association to the workspace_resources entry of the compute on which it runs.

When the coder_agent resource is created in this provider, it generates itself a new token. This token is persisted to the database in https://github.com/coder/coder/blob/9469b78290674238e1d94cdee41a5cfec13374ec/provisioner/terraform/resources.go#L338-L342

When a prebuild is claimed, we run another terraform apply to effect any desired changes.

It should be noted that the VM and the agent will ONLY be created in the provider (i.e. AWS) on the first terraform apply (when the prebuild is created), and the VM should ONLY be modified in-place on subsequent applyes.

After the second apply, the control plane will then issue an instruction for the agent to "reinitialize". This effectively just means fetching a new manifest from the control plane, which will include the new ownership information. As stated above, the actual VM or running agent process will not be recreated, and therefore the running agent needs to retain its token that it was initially launched with.

We should pass down the running agent's token to the provider to replace the autogenerated token, for this purpose.

The subsequently created workspace_agents record will contain the auth token of the initial build (i.e. prebuild creation), and this will mean that the agent's authentication will succeed via https://github.com/coder/coder/blob/5841c0a/coderd/httpmw/workspaceagent.go#L60.

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant