terraform

Commit Graph

Author	SHA1	Message	Date
Martin Atkins	88e76fa9ef	configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.	7 years ago
Martin Atkins	c5aa5c68bc	plans/objchange: Don't panic when dynamic-typed attrs are present When dynamically-typed attributes are in the schema, we use different conventions for representing nested blocks containing them (using tuples and objects instead of lists and maps). The normalization code here doesn't deal with those because the legacy SDK never generates them, but we must still pass them through properly or else other SDKs will be blocked from using dynamic attributes. Previously this function would panic in that situation. Now it will just pass through nested blocks containing dynamic attribute values entirely as-is, with no normalization whatsoever. That's okay, because the scope of this function is only to normalize inconsistencies that the legacy SDK is known to produce, and the legacy SDK never produces dynamic-typed attributes.	7 years ago
Martin Atkins	c280c27d87	plans/objchange: func NormalizeObjectFromLegacySDK Now that we have an opt-out to let the legacy SDK return values that are inconsistent with the new conventions for representing configuration, various parts of Terraform must now be prepared to deal with inconsistencies. This function normalizes the most egregious inconsistencies relating to the representation of nested blocks, freeing any recipient of its result from worrying about these inconsistencies itself.	7 years ago

Author

SHA1

Message

Date

Martin Atkins

88e76fa9ef

configs/configschema: Introduce the NestingGroup mode for blocks

In study of existing providers we've found a pattern we werent previously
accounting for of using a nested block type to represent a group of
arguments that relate to a particular feature that is always enabled but
where it improves configuration readability to group all of its settings
together in a nested block.

The existing NestingSingle was not a good fit for this because it is
designed under the assumption that the presence or absence of the block
has some significance in enabling or disabling the relevant feature, and
so for these always-active cases we'd generate a misleading plan where
the settings for the feature appear totally absent, rather than showing
the default values that will be selected.

NestingGroup is, therefore, a slight variation of NestingSingle where
presence vs. absence of the block is not distinguishable (it's never null)
and instead its contents are treated as unset when the block is absent.
This then in turn causes any default values associated with the nested
arguments to be honored and displayed in the plan whenever the block is
not explicitly configured.

The current SDK cannot activate this mode, but that's okay because its
"legacy type system" opt-out flag allows it to force a block to be
processed in this way anyway. We're adding this now so that we can
introduce the feature in a future SDK without causing a breaking change
to the protocol, since the set of possible block nesting modes is not
extensible.

Martin Atkins

c5aa5c68bc

plans/objchange: Don't panic when dynamic-typed attrs are present

When dynamically-typed attributes are in the schema, we use different
conventions for representing nested blocks containing them (using tuples
and objects instead of lists and maps).

The normalization code here doesn't deal with those because the legacy
SDK never generates them, but we must still pass them through properly or
else other SDKs will be blocked from using dynamic attributes.

Previously this function would panic in that situation. Now it will just
pass through nested blocks containing dynamic attribute values entirely
as-is, with no normalization whatsoever. That's okay, because the scope
of this function is only to normalize inconsistencies that the legacy
SDK is known to produce, and the legacy SDK never produces dynamic-typed
attributes.

Martin Atkins

c280c27d87

plans/objchange: func NormalizeObjectFromLegacySDK

Now that we have an opt-out to let the legacy SDK return values that are
inconsistent with the new conventions for representing configuration,
various parts of Terraform must now be prepared to deal with
inconsistencies.

This function normalizes the most egregious inconsistencies relating to
the representation of nested blocks, freeing any recipient of its result
from worrying about these inconsistencies itself.

3 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)