-
Notifications
You must be signed in to change notification settings - Fork 87
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 users to configure timeouts on a per-resource basis #421
Labels
enhancement
New feature or request
Comments
My thought in terms of implementation was to have something like: ---
apiVersion: whatever/v1beta1
...
spec:
timeouts:
create: ""
read: ""
update: ""
delete: "" I think either annotations or defining it in the spec is fine I just think it depends on how long term we see the need for this ability in upjet. I think if we are long term wanting this functionality then we should plan for it in the spec. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem are you facing?
In crossplane-contrib/provider-upjet-aws#1346, a crossplane user reported timeout errors restoring a large RDS database from a snapshot, which takes more than an hour. In this particular case (restoring from a db snapshot) creating the resource requires much longer than simply creating a new, empty, resource, so the default timeout from the terraform provider (40 minutes) is insufficient.
How could Upjet help solve your problem?
While upjet already allows provider authors to set timeouts in the resource
config
, and defaults to the terraform provider's timeouts if those are unset, it would be helpful to allow a third layer, which could be set by the user on a per-resource basis, to indicate "This resource is different than a typical one of itsKind
, and needs a different timeout". It would also allow for fast self-service workarounds when users report timeout issues, without requiring them to wait for a code change to the provider.I think an annotation seems like a natural place to specify this, as it seems like the sort of thing that would almost always be omitted, but useful to be able to specify when needed.
As an initial proposal, I'd suggest
as annotation keys, with any string that can be parsed to a golang duration as the value.
@blakeromano suggested at the SIG-Upjet meeting that he might prefer a
spec
field similar tomanagementPolicies
. I'll let him speak for himself here if he wants to describe that more fully.The text was updated successfully, but these errors were encountered: