-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow configuring custom timeouts for Create, Update, Delete operations on a per-resource basis #2655
Comments
@lukehoban When is this likely to be implemented? |
@naveensrinivasan We're hoping to be able to tackle this as part of the current milestone. |
So I have been looking at how we will do this over the past few days. The user part is going to look as follows (using AWS DynamoDB Table as an example because Terraform supports customTimeouts):
This means we will be extending the ResourceOpt struct to support this new option that we can pass to the resource. @ellismg / @lukehoban / @jen20 I'd love for you guys to have your thoughts on this - as this will be forming the basis of work here. |
@stack72 That looks right to me. I assume this will get passed directly through to the providers, and they will have to figure out how to implement them? (That is, that this is not a feature of the engine like e.g. Notably, I don't believe we've had any resource options like this so far that are passed through to providers. So far, all the resource options have been interpreted by the Pulumi engine. This raises some questions around what should happen if the provider can't implement the requested custom timeouts, whether the full set of configuration here is going to look sufficiently the same across all providers, etc. I think the answer is that we do want a consistent model to present across all providers, and that extending the provider RPC interface to pass these custom timeouts down is the right thing to do. cc also @pgavlin for thoughts |
I think that's going to be necessary, yes. TF will certainly need to take this approach.
I agree. Even if certain providers are unable to implement the custom timeouts, I do think that plumbing this through the RPC interface is the right move. Perhaps we can generate static typings or early errors that indicate that custom timeouts are unavailable for certain resources. |
Related to pulumi/pulumi-kubernetes#457 I added timeout logic for the k8s provider using annotations, but this would be useful as a more general-purpose way of setting that. |
Here are some links for anyone that comes across this in the future:
|
For anyone looking for where Custom Timeouts have been moved to: https://www.pulumi.com/docs/intro/concepts/resources/#options |
I've been trying Custom Timeouts with azure-native and have found that (compared to not using |
There are scenarios where the default timeouts in the provider are insufficient. In order to allow users to not be blocked, we should allow configuring custom timeouts.
The text was updated successfully, but these errors were encountered: