-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
aws_workspace: Timeout reached on creation #13598
Comments
This is a critical usability change. In us-east-1, there's about a 50-50 chance that a Workspace create will timeout. It's unusable for automation in its current state. Successful deploys take at least 20 minutes, and often skirt the edge of 30 minutes and just squeeze under. I don't know if other regions are faster, but this simply cannot be used for automated deploys in us-east-1 in its current state. |
Since this seems valid that the default timeout is too low. If anyone here would like to adjust this, it can be done by updating |
It would be better if it could be configured. Really, all resources should support adjustable timeouts, the way e.g. |
+1, I second @fweep in having a configurable option wrt timeouts not just for WS, but for other services like RDS, Aurora etc that take longer times to be created/updated. |
+1, am helping a Windows IT team move to the cloud with an infrastructure-as-code mindset. Don't want to retreat and use CloudFormation. Help appreciated! |
Hi there, I've recently added timeout attributes to |
Given the resource now supports configurable timeouts and since there has been no further activity here, I'm going to close this issue. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Community Note
Terraform Version
Terraform v0.12.24
Affected Resource(s)
Terraform Configuration Files
resource "aws_workspaces_workspace" "workspace_racker" {
directory_id = module.directory.directory_id
bundle_id = data.aws_workspaces_bundle.standard_windows_10.id
user_name = "racker-test"
workspace_properties {
compute_type_name = data.aws_workspaces_bundle.standard_windows_10.compute_type[0].name
user_volume_size_gib = data.aws_workspaces_bundle.standard_windows_10.user_storage[0].capacity
root_volume_size_gib = data.aws_workspaces_bundle.standard_windows_10.root_storage[0].capacity
running_mode = "AUTO_STOP"
running_mode_auto_stop_timeout_in_minutes = 60
}
tags = {
Environment = "Development"
}
}
Debug Output
aws_workspaces_workspace.workspace_racker: Still creating... [29m1s elapsed]
aws_workspaces_workspace.workspace_racker: Still creating... [29m11s elapsed]
aws_workspaces_workspace.workspace_racker: Still creating... [29m21s elapsed]
aws_workspaces_workspace.workspace_racker: Still creating... [29m31s elapsed]
aws_workspaces_workspace.workspace_racker: Still creating... [29m41s elapsed]
aws_workspaces_workspace.workspace_racker: Still creating... [29m51s elapsed]
aws_workspaces_workspace.workspace_racker: Still creating... [30m1s elapsed]
Error: workspace "ws-7dq7plqrv" is not available: timeout while waiting for state to become 'AVAILABLE' (last state: 'PENDING', timeout: 30m0s)
on main.tf line 134, in resource "aws_workspaces_workspace" "workspace_racker":
134: resource "aws_workspaces_workspace" "workspace_racker" {
Panic Output
Expected Behavior
Workspace creation should be successful
Actual Behavior
Workspace creation reaches a timeout and the state is not updated successfully. Either the internal timeout should be updated or the nested block timeouts should be allowed, just like RDS
Steps to Reproduce
terraform apply
Important Factoids
References
The text was updated successfully, but these errors were encountered: