When a template is configured with prebuilds, we terraform apply the template first to provision the prebuild using the prebuilds identity, and then once more once it has been claimed by a user.
The second apply could result in resources being replaced if the resource definition relies upon the identity.
Example:
resource "google_compute_instance" "dev" {
count = data.coder_workspace.me.start_count
name = "coder-${lower(data.coder_workspace_owner.me.name)}-${lower(data.coder_workspace.me.name)}-root"
...
Upon first apply the name of this resource will be coder-prebuilds-prebuild-1234-root, the second one coder-danny-myfirstworkspaceyay-root. GCP and other providers generally do not allow resource names to be reconfigured after provisioning, so the resource would be replaced with a new one, obviating the benefit of prebuilds.
There are many situations under which a replacement could occur, not just for the name attribute, and it's impossible to warn upfront comprehensively.
In the current implementation we're detecting this replacement and providing a warning, but this may be missed by template admins.
We may need to augment the template import process to allow for prebuild validation.
This would entail creating a prebuild imperatively and performing a terraform plan using a new identity to determine the proposed changes. This would incur some cost, but it's likely negligible.
The flow could be something like this:
- Template admin imports a new template/version
- Prebuilds are detected
- Popup appears offering to validate prebuild configuration
- "OK" is pressed, kicking off the provisioning of a prebuild
- The UI follows the logs and waits for the workspace to provision
- Once completed, it runs a
terraform plan with a different identity injected, to detect replacements
- If found, UI displays warnings for all resource attributes which will cause a replacement, and offer docs / advice on how to rectify (i.e. add
ignore_changes)
When a template is configured with prebuilds, we
terraform applythe template first to provision the prebuild using theprebuildsidentity, and then once more once it has been claimed by a user.The second
applycould result in resources being replaced if the resource definition relies upon the identity.Example:
Upon first
applythe name of this resource will becoder-prebuilds-prebuild-1234-root, the second onecoder-danny-myfirstworkspaceyay-root. GCP and other providers generally do not allow resource names to be reconfigured after provisioning, so the resource would be replaced with a new one, obviating the benefit of prebuilds.There are many situations under which a replacement could occur, not just for the
nameattribute, and it's impossible to warn upfront comprehensively.In the current implementation we're detecting this replacement and providing a warning, but this may be missed by template admins.
We may need to augment the template import process to allow for prebuild validation.
This would entail creating a prebuild imperatively and performing a
terraform planusing a new identity to determine the proposed changes. This would incur some cost, but it's likely negligible.The flow could be something like this:
terraform planwith a different identity injected, to detect replacementsignore_changes)