You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
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 theworkspace_agents
table uponterraform apply
. All other template collateral, including the VM/container/whatever on which the agent runs, will be recorded in theworkspace_resources
table. The agent has an FK association to theworkspace_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-L342When 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 subsequentapply
es.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.The text was updated successfully, but these errors were encountered: