Hi,
I am new to Terraform. This may be something obvious but I notice when I look up a resource on the Terraform registry pages, the Argument Reference section does not have data types specified. How do people figure out the proper data types, e.g. string, number, list, etc to use? Thanks.
Hi @iacac,
Unfortunately as you’ve seen the documentation often leaves the expected data type vague by using statements such as “a list of IDs” (probably a list of strings) or “an ID” (probably a string). This is an unfortunate result of many of these providers now being quite old and a lot of their existing documentation being written and maintained manually over time by human documentation authors who didn’t always do so consistently.
We have been gradually switching to generated documentation in some cases, which can therefore be more systematic about mentioning metadata like this, but I understand that isn’t much consolation if the resource types you are interested in don’t have that yet.
Although far from an ideal solution, you can access the provider’s own internal schema metadata (what the documentation would ideally be generated from) by getting the provider installed using terraform init and then executing the following command:
terraform providers schema -json
The result will be a likely-very-large JSON blob describing the schema of everything in every provider you use, and so at the very list you’ll probably want to prettify the layout by piping it into a tool like jq.
In that JSON data structure you’ll see for each resource type that it has a property "block" which describes the schema of its top-level block. Inside that is "attributes" which describes both the arguments and result attributes in that top-level block, including a property "type" which gives the specific type constraint Terraform Core will enforce on the provider’s behalf.
I happen to have a configuration open on my system which uses the hashicorp/null provider and so I ran that command to produce a relatively-small example showing the null_resource resource type:
{
"format_version": "1.0",
"provider_schemas": {
"registry.terraform.io/hashicorp/null": {
"resource_schemas": {
"null_resource": {
"version": 0,
"block": {
"attributes": {
"id": {
"type": "string",
"description": "This is set to a random value at create time.",
"description_kind": "markdown",
"computed": true
},
"triggers": {
"type": [
"map",
"string"
],
"description": "A map of arbitrary strings that, when changed, will force the null resource to be replaced, re-running any associated provisioners.",
"description_kind": "markdown",
"optional": true
}
},
"description": "The `null_resource` resource implements the standard resource lifecycle but takes no further action.\n\nThe `triggers` argument allows specifying an arbitrary set of values that, when changed, will cause the resource to be replaced.",
"description_kind": "markdown"
}
}
}
}
}
}
In this example id has "type":"string", which corresponds with the Terraform language type constraint string. triggers has "type":["map","string"] which is a JSON serialization of the Terraform language type constrant map(string). The other type constraints all follow a similar pattern of using plain JSON strings for primitive types and JSON arrays to represent complex types.
With that said, I typically don’t refer to this machine-oriented output and instead rely on the examples and natural-language descriptions on the documentation pages and know that if I get it wrong Terraform will either automatically convert the value for me or return an error explaining why it couldn’t; I’m describing the above only as a last resort if you really need to see the actual type constraint, but it’s a lot of work to do in the common case.
I hope this helps at least a little!
Hi @apparentlymart
Thank you so much for the detailed explanation and the workaround. I really appreciate you spent the time to explain it!