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
We're planning on adding support for custom timeouts to all resources as a part of 2.0 (which we're working on the dependencies for at the moment) - as such we should be able to tackle this then. If it's helpful in the interim it could be possible to bump this timeout to an hour (as an example) - however this will ultimately be solved via custom timeouts which are being tracked in #417.
Rather than having multiple issues open tracking the same thing (since we plan to support this across all resources at once, as this is a behavioural change) I'm going to close this issue in favour of #171 - would you mind subscribing to that issue for updates?
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. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!
ghost
locked and limited conversation to collaborators
Sep 29, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If you change an existing azure security center workspace (azurerm_security_center_workspace) with a new workspace, it fails after 30 mins
A similar issue was reported in closed bug #2718 for creation and the timeout was extended from 15m to 30m.
The scenario here is different as I need to deal with a situation where I have to change the workspace that was set to a security centre
A possible improvement is to implement the new timeout block to go beyond 30 mins?
If I redo a terraform apply after the initial failure it completes successfully.
The text was updated successfully, but these errors were encountered: