"timeouts":设置超时后 terraform 状态为空:架构中的 &schema.ResourceTimeout{}
"timeouts": null in terraform state after setting Timeouts: &schema.ResourceTimeout{} in schema
上下文:向 TF 提供程序添加新资源
在我阅读了 HashiCorp 关于 Retries and Customizable Timeouts 的教程并弄清楚创建(使用 StateChangeConf
)可能需要超过默认 20 分钟的创建操作后,我为资源设置了自定义超时:
return &schema.Resource{
CreateContext: fooCreate,
Schema: map[string]*schema.Schema{...}
Timeouts: &schema.ResourceTimeout{
Create: schema.DefaultTimeout(2 * Time.Hour),
}
},
...
func fooCreate(ctx context.Context, d *schema.ResourceData, meta interface{}) diag.Diagnostics {
...
createStateConf := &resource.StateChangeConf{
...
Timeout: 1 * Time.Hour,
...
}
Important If using a CRUD function with a timeout, any StateChangeConf timeouts should be configured below that duration to avoid returning the SDK context: deadline exceeded error instead of the retry logic error.
如果我不设置 Timeouts
我的 TF 状态文件看起来不错,但是在我添加它们之后我可以看到一个新的 "timeouts": null
属性,它看起来有点粗略,这是预期的吗?
有趣的是,我认为即使在我添加此覆盖之前,创建工作也很完美(花了大约 1 小时):
Timeouts: &schema.ResourceTimeout{
Create: schema.DefaultTimeout(2 * Time.Hour),
}
所以我想知道是否有必要。
免责声明 :: 绝不是,我是 golang
专家,但我想我对此有一些了解。
我已经根据 azurerm
提供商检查了我们的 tfstate
文件,确实在各种资源上找到了 "timeouts": null
。
不过,经历了here提到的问题后,null
确实是预料之中的。 hashicorp
团队提供的解释如下..
The "timeouts" field in the state is only representative of the
configuration values. Terraform core isn't aware of the default
values, as those are looked up at runtime by the provider SDK. The
provider SDK does encode the timeouts into the "private" field for
later reference however. There was an issue with delete timeout values
being lost at one point, but that should only show up with an old AWS
provider as it's been fixed for a few months.
这意味着,我们应该查看字段 private
而不是 timeouts
。事实上,我们的状态文件有 "private": "eyJlMmJmYjczMC1lY2FhLTExZTYtOGY4OC0zNDM2M2JjN2M0YzAiOnsiY3JlYXRlIjoxODAwMDAwMDAwMDAwLCJkZWxldGUiOjE4MDAwMDAwMDAwMDAsInJlYWQiOjMwMDAwMDAwMDAwMCwidXBkYXRlIjoxODAwMDAwMDAwMDAwfX0=",
。它是 base64
编码的。
当我解码时,我看到下面的输出。
echo "eyJlMmJmYjczMC1lY2FhLTExZTYtOGY4OC0zNDM2M2JjN2M0YzAiOnsiY3JlYXRlIjoxODAwMDAwMDAwMDAwLCJkZWxldGUiOjE4MDAwMDAwMDAwMDAsInJlYWQiOjMwMDAwMDAwMDAwMCwidXBkYXRlIjoxODAwMDAwMDAwMDAwfX0=" | base64 -d
{"e2bfb730-ecaa-11e6-8f88-34363bc7c4c0":{"create":1800000000000,"delete":1800000000000,"read":300000000000,"update":1800000000000}}
上述超时密钥是 here 中 terraform-core
中的硬编码字符串。您必须看到您在提供商中指定的 crud
级超时(以纳秒为单位)。
您是否通过解码 tfstatefile 的 private
字段看到它们?
上下文:向 TF 提供程序添加新资源
在我阅读了 HashiCorp 关于 Retries and Customizable Timeouts 的教程并弄清楚创建(使用 StateChangeConf
)可能需要超过默认 20 分钟的创建操作后,我为资源设置了自定义超时:
return &schema.Resource{
CreateContext: fooCreate,
Schema: map[string]*schema.Schema{...}
Timeouts: &schema.ResourceTimeout{
Create: schema.DefaultTimeout(2 * Time.Hour),
}
},
...
func fooCreate(ctx context.Context, d *schema.ResourceData, meta interface{}) diag.Diagnostics {
...
createStateConf := &resource.StateChangeConf{
...
Timeout: 1 * Time.Hour,
...
}
Important If using a CRUD function with a timeout, any StateChangeConf timeouts should be configured below that duration to avoid returning the SDK context: deadline exceeded error instead of the retry logic error.
如果我不设置 Timeouts
我的 TF 状态文件看起来不错,但是在我添加它们之后我可以看到一个新的 "timeouts": null
属性,它看起来有点粗略,这是预期的吗?
有趣的是,我认为即使在我添加此覆盖之前,创建工作也很完美(花了大约 1 小时):
Timeouts: &schema.ResourceTimeout{
Create: schema.DefaultTimeout(2 * Time.Hour),
}
所以我想知道是否有必要。
免责声明 :: 绝不是,我是 golang
专家,但我想我对此有一些了解。
我已经根据 azurerm
提供商检查了我们的 tfstate
文件,确实在各种资源上找到了 "timeouts": null
。
不过,经历了here提到的问题后,null
确实是预料之中的。 hashicorp
团队提供的解释如下..
The "timeouts" field in the state is only representative of the configuration values. Terraform core isn't aware of the default values, as those are looked up at runtime by the provider SDK. The provider SDK does encode the timeouts into the "private" field for later reference however. There was an issue with delete timeout values being lost at one point, but that should only show up with an old AWS provider as it's been fixed for a few months.
这意味着,我们应该查看字段 private
而不是 timeouts
。事实上,我们的状态文件有 "private": "eyJlMmJmYjczMC1lY2FhLTExZTYtOGY4OC0zNDM2M2JjN2M0YzAiOnsiY3JlYXRlIjoxODAwMDAwMDAwMDAwLCJkZWxldGUiOjE4MDAwMDAwMDAwMDAsInJlYWQiOjMwMDAwMDAwMDAwMCwidXBkYXRlIjoxODAwMDAwMDAwMDAwfX0=",
。它是 base64
编码的。
当我解码时,我看到下面的输出。
echo "eyJlMmJmYjczMC1lY2FhLTExZTYtOGY4OC0zNDM2M2JjN2M0YzAiOnsiY3JlYXRlIjoxODAwMDAwMDAwMDAwLCJkZWxldGUiOjE4MDAwMDAwMDAwMDAsInJlYWQiOjMwMDAwMDAwMDAwMCwidXBkYXRlIjoxODAwMDAwMDAwMDAwfX0=" | base64 -d
{"e2bfb730-ecaa-11e6-8f88-34363bc7c4c0":{"create":1800000000000,"delete":1800000000000,"read":300000000000,"update":1800000000000}}
上述超时密钥是 here 中 terraform-core
中的硬编码字符串。您必须看到您在提供商中指定的 crud
级超时(以纳秒为单位)。
您是否通过解码 tfstatefile 的 private
字段看到它们?