Open magodo opened 2 years ago
Drive-by note: I'm guessing the framework's handling for this wouldn't have this issue as it does not treat the timeouts
configuration different from any other attribute. The framework allows customization of no-change plans, if necessary.
If you want to try it out, here's some information:
I can confirm I'm facing the same issue and my timeout only changes were never picked up, at least until I forced a dummy change to the resource, but it's not always that easy to do.
I am also facing the same issue. Increasing time out does noy fix my issue and I am CAF module for private dns zone and azurerm_private_dns_zone_virtual_network_link
SDK version
Use-cases
Deploy following config:
The default timeouts are set:
Adding the
timeouts
forread = "10m"
, and refresh, the stored meta in state is not changed for the read timeout:Also, the
terraform plan
shows no diff.The only way to update the timeout is to change something in the resource to trigger an apply:
This is fine in most cases, as simply updating the timeout for the resource is meaningless, until any operation happens to the resource, i.e. when applying.
However, there is an unfortunate fact that the new timeout only takes effect after the plan stage (
PlanResourceChange
in context of the proto) during apply, but not before, i.e. the read (ReadResource
in context of the proto) during refresh is still using the old read timeout. This causes issues like https://github.com/hashicorp/terraform-provider-azurerm/issues/14213, where users are managing a collection of same typed resources, the default timeout of it is not long enough to finish the read. In that case, changing thetimeout
for read doesn't work for theterraform apply
/terraform plan
as the refresh part will still use the old timeout, results into timeout.The workaround for this is:
-fresh=false
to avoid refreshing)Both solutions seem not ideal, it would be cool if we can detect the diff for
timeouts
and make an apply to update it.