terraform-provider-mailgun
terraform-provider-mailgun copied to clipboard
Add support for customizable timeouts
Terraform Version
Terraform v1.1.6
on linux_amd64
+ provider registry.terraform.io/wgebis/mailgun v0.7.2
Affected Resource(s)
Please list the resources as a list, for example:
- mailgun_domain
Terraform Configuration Files
resource "mailgun_domain" "domain" {
name = "test.domain.com"
region = "us"
spam_action = "tag"
dkim_key_size = 2048
}
Expected Behavior
We should be able to configure the mailgun_domain
timeouts for the create and delete operations as Terraform currently proposes. Example:
resource "mailgun_domain" "domain" {
name = "test.domain.com"
region = "us"
spam_action = "tag"
dkim_key_size = 2048
timeouts {
create = "5m"
delete = "10m"
}
}
Actual Behavior
The mailgun_domain
resource is constantly timing out while destroying the domain. It seems that Mailgun API is taking more time to destroy the domains and the default value (1 minute) for the destroy timeout is not enough and we cannot set a new value.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
-
terraform apply
-
terraform destroy
References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
Thanks for the ticket, I'm going to validate if the timeout are available via Mailgun Go SDK, if so, I will take into consideration implement them while making next release. 👍
Thank you @wgebis for considering implementing this.
Meanwhile, we are having a considerable number of destroy timeouts on the mailgun_domain
resource (9 out of 10 to be more precise). It seems that Mailgun is taking a lot more time to sync all their systems about the removal status of a domain.
The error we are getting is this one:
│ Error: domain seems to still exist; will check again
Is it possible to release a patch to increment the retry time limit for deletion until we don't have the custom timeouts in place?
Hi!
Is it possible to fix the mailgun_domain
destroy timeout issue mentioned in the comment above?
This is causing the provider to be nearly unusable at the destroy phase.
Hey @mmf55 I've got the exact same issue, using Pulumi which uses this Terraform provider under the hood. Just like you, the domain is almost entirely unusable at this point and in our case it breaks SLA with our cloud customers. The mention from above is my issue on the Pulumi provider repo.
I would really like to see a fix for this @wgebis as mailgun_domain
simply doesn't work right now.
I'm sure you've got your own workaround that may be better @mmf55 (and please share if you do!), but personally I've been doing the following:
- Let the deletion fail.
- Delete the resource from the state.
- Run the deletion again.
Thanks for reporting. I will keep in mind it with further development. Sadly lack of time now 😔.
Hi @kiweezi !
Since this has been happening for a long time, we decided to call the Mailgun API directly using a null_resource
as an alternative for domain creation and deletion to avoid any manual intervention on the Terraform state.
Thanks for sharing that @mmf55, that surely is a better workaround than ours! I will certainly account for it in our decision. And thank you for your quick response @wgebis. Please don't worry and take your time.
Sorry to disturb @wgebis, but is this the commit that should fix the timeout issue? If so, is it just a case of getting this into the next release?
Yes. It is on master branch and will be in next release.
That's great! I look forward to it.
@wgebis would it be possible to make a release so we can close our own issue here?
- https://github.com/pulumi/pulumi-mailgun/issues/119
I can see there has not been a release since December 2022, does anyone know when the next release will be created? Would be nice to have this resolved 🙂.
@wgebis any ideas when the next release will be?
Can we get an update on this one @wgebis?
@RyanS-J Hi there! The new version with hardcoded longer timeout has been just cut off. I leave this issue as opened with label enhancement
for making configurable timeouts in the future.