Consider adding (deprecated) support for blocks 😢 #85
Comments
paddycarver
added
the
sdkv2-parity
|
To further hone on the proposal, I presume:
|
aareet
added
the
design-doc
|
Next step: create an epic with more granular implementation so we can discuss with provider devs and get their input on which path is preferable. |
|
If deprecation of nested block syntax is planned, the documentation at https://www.terraform.io/docs/language/attr-as-blocks.html should probably be updated ASAP to no longer recommend it over nested attribute syntax. Otherwise, providers using the framework will face confusion from users as to why the "recommended" syntax is not allowed. Lack of support for nested blocks might also be worth a mention at https://www.terraform.io/docs/plugin/which-sdk.html. |
paddycarver
added
the
schema
|
I think that's a slightly confusing "we don't have good terms around this yet" case. SDKv2 can't currently use the recommended syntax, which is a framework-only feature. Likewise, the "which SDK?" update may be more confusing than illuminating, as there's not really a difference in capability, just in syntax. Unsure, though. 🤔 |
|
FWIW, the intent of that "Attributes as Blocks" page is only to describe the funny special-case behavior for the arguments which use that weird legacy mode. It's not a recommendation to do anything in particular. Its intended audience is end-users of providers that use the mechanism, to explain the end-user-visible consequences of using that special mode. |
Reference: #85 This implementation is analogous to the existing `Attributes` field on `Attribute`. While the framework handles the major differences at the protocol layer during conversion, it also must enforce the constraints of the underlying type system. Some notable features include: * Defining schemas is very similar to `Attributes`. * Accessing and writing `Config`, `Plan`, and `State` data is no different than `Attributes` with the same nesting mode. * Blocks are structural by Terraform's and cty's definition, meaning there is no concept of `Computed`, `Optional`, `Required`, or `Sensitive`. Checks are in place to enforce these constraints. The primary purpose for supporting blocks is to allow previously existing schemas defined by the older Terraform Plugin SDK to not require practitioner breaking changes upon migrating to the framework (except the protocol version and therefore the minimum Terraform CLI version). This also allows this framework to be muxed with the older framework since the provider schema must match. It is expected that over time any schema definitions including `Blocks` will migrate to `Attributes`. Provider developers should always opt for `Attributes` in new schema definitions.
Reference: #85 This implementation is analogous to the existing `Attributes` field on `Attribute`. While the framework handles the major differences at the protocol layer during conversion, it also must enforce the constraints of the underlying type system. Some notable features include: * Defining schemas is very similar to `Attributes`. * Accessing and writing `Config`, `Plan`, and `State` data is no different than `Attributes` with the same nesting mode. * Blocks are structural by Terraform's and cty's definition, meaning there is no concept of `Computed`, `Optional`, `Required`, or `Sensitive`. Checks are in place to enforce these constraints. The primary purpose for supporting blocks is to allow previously existing schemas defined by the older Terraform Plugin SDK to not require practitioner breaking changes upon migrating to the framework (except the protocol version and therefore the minimum Terraform CLI version). This also allows this framework to be muxed with the older framework since the provider schema must match. It is expected that over time any schema definitions including `Blocks` will migrate to `Attributes`. Provider developers should always opt for `Attributes` in new schema definitions.
Reference: #85 The primary purpose for supporting blocks is to allow previously existing schemas defined by the older Terraform Plugin SDK to not require practitioner breaking changes upon migrating to the framework (except the protocol version and therefore the minimum Terraform CLI version unless a tfprotov5 server implementation is added to this framework as well). This also allows this framework to be muxed with the older framework since the provider schema must match. It is expected that over time any schema definitions including `Blocks` will migrate to `Attributes`. Provider developers should always opt for `Attributes` in new schema definitions. One notable exclusion to this initial block support is plan modification, both with attributes under blocks and blocks themselves. Support for this functionality can be tracked in #222.
|
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. |
Module version
Use-cases
We decided to model nested fields as nested attributes, because they're better in basically every way™, and I think that was a good decision.
However, for providers that currently exist and want to adopt the framework using mux, this presents two problems:
=to their configuration. Meaning piecemeal migration of resources is not possible, as you can't model blocks in the framework, and need to migrate to nested attributes at that point, which is a practitioner-visible change.Both of these problems severely limit how palatable our migration story can be.
Attempted Solutions
I thought about just relaxing mux to consider blocks and nested attributes the same for considering whether provider blocks are "equivalent" or not, as they'll both show up as objects in the config and can be accessed the same way. But that seems brittle, and would lead to weird situations where things aren't treated as sensitive properly, or where things can be expressed in the framework that SDKv2 doesn't know how to handle... it just feels like a really leaky abstraction and lossy mapping. It also doesn't address point 2 basically at all.
Proposal
I'm proposing that we add support to the framework for modeling blocks, and make it clear from its introduction that it is deprecated, we recommend everyone use nested attributes, and that it's only supported to ease migration from SDKv2. This isn't ideal, but I don't see a way to get a clean, piecemeal, non-practitioner-impacting migration strategy if we don't.
The text was updated successfully, but these errors were encountered: