Hi, folks. First question here.
Can anyone point me to any resource in any provider that allows labels in nested blocks?
The docs state that it is possible, but I lack the search-fu to find a working example.
This is the hypothetical example from the docs:
- Sometimes nested blocks are defined as taking a logical key to identify each block, which serves a similar purpose as the resource’s own name by providing a convenient way to refer to that single block in expressions. If
aws_instance
had a hypothetical nested block type device
that accepted such a key, it would look like this in configuration:
device "foo" {
size = 2
}
device "bar" {
size = 4
}
Arguments inside blocks with keys can be accessed using index syntax, such as aws_instance.example.device["foo"].size
.
Hi @thiagoarrais,
No official provider currently does this because doing so would require the provider to end compatibility with Terraform 0.11, where that capability isn’t available.
In principle a provider written only for the new protocol could do it, but so far that’s been true only of some early prototypes, like my own testing
provider prototype, which uses labelled blocks for the nested blocks inside the testing_assertions
data source. It can do so only because it’s explicitly a Terraform 0.12-only experiment, not written in the usual way (it doesn’t use the official Terraform SDK).
The documentation is written to be ready for that becoming available, because in principle it’s technically possible for it to happen today for this sort of “non-standard” provider and it will start to show up in official providers once they begin to phase out compatibility with Terraform 0.11 in the future.
1 Like
Nice. I see that the testing provider uses an experimental SDK of yours. What is the roadmap for it? Will it make into the official SDK? Will that give birth to another 0.12-only SDK?
I’m writing a (currently) private provider and would really like to tap into that. Do you know if there is a Github issue, pull request or forum post I can upvote and subscribe to?
My SDK prototype is not a HashiCorp project; I built it purely for side-projects like the testing
provider here (which is also not a HashiCorp project) and I have no current plans to invest in it further because I’m currently spending my spare time on other things.
Part of the Terraform team will be working on an updated SDK, which will likely take some learnings from my prototype and some others that have been built by other folks, but I’m not on that team so I don’t have any specifics on what form it might take.
There is no single GitHub issue for updating the SDK because there are many different aspects of it. You can find some of them by looking in the main Terraform repository for issues labelled provider-sdk
. For the moment, compatibility with existing providers and with Terraform 0.11 is the main concern and so I believe the next steps for that team will be to figure out how to navigate this transition which is likely to include at least a small number of breaking API changes.
1 Like