Allow providers' schema to define named HCL blocks

[radeksimko]

Current situation

Providers can specify "unnamed" blocks, i.e.

rule {
  attribute1 = "value1"
  attribute2 = 42
}

Goal

Providers should have the flexibility to specify named blocks, i.e.

rule "name" {
  attribute1 = "value1"
  attribute2 = 42
}

---

Example Use Cases

nomad_job

Currently in the nomad_job resource the jobspec is accepted as a string.

By supporting named blocks we can accept HCL config directly, e.g.

group "foo" {
    task "foo" {
       ...

https://www.terraform.io/docs/providers/nomad/r/job.html#example-usage

[apparentlymart]

I think this one is a "protocol-5-only" situation, because the flatmap representation of values in protocol 4 and earlier cannot represent this sort of labelled nested structure without either significant changes to how the keys are formatted (which would likely upset the flatmap parser in Terraform 0.11) or constraining the block label to contain only identifier characters.

The protocol 5 schema has the block nesting mode MAP which will cause Terraform Core to expect labelled blocks like you described here and pass them to the provider as a map, if there were a way to describe such a thing in the SDK-level schema.

[bflad]

I think where we landed with this was that while this SDK could introduce map block support here (potentially a large amount of effort? not sure that side of this has been investigated), the code paths (difference handling, etc.) on the Terraform CLI side of this could have a lot of unknown-unknowns since its never been practical to implement before. Given that this SDK is supported by many now non-backportable versions of Terraform CLI (0.12, 0.13, 0.14, 0.15), it could create situations where practitioners are stuck between not being able to upgrade to potentially problematic provider versions or be forced to upgrade Terraform CLI, which is certainly less than ideal.

Over in terraform-plugin-framework, the prospect of introducing map block support is much more straightforward given its design and data handling, however that SDK also implements map nested attributes, which effectively are going to be the recommended replacement for map blocks.

Happy to discuss this more, but I think the best thing to do with this enhancement in this SDK is to close it. If there's enough of compelling use case to require map block support and everyone is okay with the potential consequences, then let's open a new issue in the new SDK. 👍

[radeksimko]

Having worked outside of SDK/provider land for a while I can't say how compelling the Nomad example is today, but even (or more so) from a distance I'd still say that our broader user base would certainly benefit in the long run if all the HashiCorp tools were more aligned in how they support HCL - at least those which have made the transition to v2 - i.e. Terraform and Nomad.

I understand it's easier said than done though. 😅

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.