We may revise this further during the Terraform v1.8 prerelease period, if
feedback suggests that more information is needed or that this information
is not clear enough. The main goal here is just to get out of the confusing
situation where the v1.8 branch contains a v1.7 upgrade guide, so that
we can link to the upgrade guide from the changelog.
The full upgrade guide page gives us room for more details, allowing the
changelog to serve just as a concise list of changes.
Using the new possibility of provider-contributed functions, this
introduces three new functions which live in the
terraform.io/builtin/terraform provider, rather than being language
builtins, due to their Terraform-domain-specific nature.
The three new functions are:
- tfvarsencode: takes a mapping value and tries to transform it into
Terraform CLI's "tfvars" syntax, which is a small subset of HCL that
only supports key/value pairs with constant values.
- tfvarsdecode: takes a string containing content that could potentially
appear in a "tfvars" file and returns an object representing the
raw variable values defined inside.
- exprencode: takes an arbitrary Terraform value and produces a string
that would yield a similar value if parsed as a Terraform expression.
All three of these are very specialized, of use only in unusual situations
where someone is "gluing together" different Terraform configurations etc
when the usual strategies such as data sources are not suitable. There's
more information on the motivations for (and limitations of) each function
in the included documentation.
The `use_legacy_workflow` argument has been removed to encourage consistency with the AWS SDKs. The backend will now search for credentials in the same order as the default provider chain in the AWS SDKs and AWS CLI.
These ideas are both already implied by some logic elsewhere in the system,
but until now we didn't have the decision logic centralized in a single
place that could therefore evolve over time without necessarily always
updating every caller together.
We'll now have the modules runtime produce its own boolean ruling about
each characteristic, which callers can rely on for the mechanical
decision-making of whether to offer the user an "approve" prompt, and
whether to remind the user after apply that it was an incomplete plan
that will probably therefore need at least one more plan/apply round to
converge.
The "Applyable" flag directly replaces the previous method Plan.CanApply,
with equivalent logic. Making this a field instead of a method means that
we can freeze it as part of a saved plan, rather than recalculating it
when we reload the plan, and we can export the field value in our export
formats like JSON while ensuring it'll always be consistent with what
Terraform is using internally.
Callers can (and should) still use other context in the plan to return
more tailored messages for specific situations they already know about
that might be useful to users, but with these flags as a baseline callers
can now just fall back to a generic presentation when encountering a
situation they don't yet understand, rather than making the wrong decision
and causing something strange to happen. That is: a lack of awareness of
a new rule will now cause just a generic message in the UI, rather than
incorrect behavior.
This commit mostly just deals with populating the flags, and then all of
the direct consequences of that on our various tests. Further changes to
actually make use of these flags elsewhere in the system will follow in
later commits, both in this repository and in other repositories.
* Update azurerm backend docs
* Use support note notation
* Fix table format
* Tidy and enhance
* Tidy warnings
* Improvements
* Add comment to CLI option
* Add warnings
* Improve example resource names
* Follow convention for warning
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Update website/docs/language/settings/backends/azurerm.mdx
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
* Apply suggestions from code review
---------
Co-authored-by: Luke Taylor <77284962+luke-taylor@users.noreply.github.com>
Co-authored-by: Tom Bamford <tom@bamford.io>
Previously, the `providers schema -json` output would include the root object from `metadata functions -json`. This object had its own `format_version` property, which would be confusing with the root `format_version` property already present.
This change still uses the `jsonfunction` package for consistency between cty and provider function JSON handling, but removes that extra object, instead making `functions` directly a mapping of names to signatures/definitions. This also adds a code comment to hint maintainers that jsonprovider format versioning is tied to jsonfunction format versioning.
Example output prior to change:
```jsonc
{
"format_version": "1.0",
"provider_schemas": {
"registry.terraform.io/bflad/framework": {
// ...
"functions": {
"format_version": "1.0",
"function_signatures": {
"example": {
"description": "Echoes given argument as result",
"summary": "Example function",
"return_type": "string",
"parameters": [
{
"name": "input",
"description": "String to echo",
"type": "string"
}
]
}
}
}
}
}
}
```
Example output after change:
```jsonc
{
"format_version": "1.0",
"provider_schemas": {
"registry.terraform.io/bflad/framework": {
// ...
"functions": {
"example": {
"description": "Echoes given argument as result",
"summary": "Example function",
"return_type": "string",
"parameters": [
{
"name": "input",
"description": "String to echo",
"type": "string"
}
]
}
}
}
}
}
```
Previously "terraform console" always evaluated in a kinda strange context
where resource instance data comes from the prior state, but other derived
of values end up being calculated dynamically based on the current
configuration, which is okay for simple cases but can be confusing if the
configuration has changed significantly since the most recent apply, or
if there haven't yet been any applied changes.
Now we'll allow an optional new mode where Terraform runs the normal plan
phase (as if running "terraform plan") and then uses the resulting
_planned state_ as the basis for evaluation, allowing evaluation against
a partial approximation of what the world ought to look like if these
changes were applied, without having to actually apply them first.
As with the previous use of the eval walk, it's possible that an erroneous
situation will still produce a partial evaluation scope, and so the
console still allows evaluation against that scope but with a caveat that
it might produce unexpected results. In practice this can be useful for
debugging situations like when unknown values block planning of an object,
to allow inspection of the values that are contributing to that blocked
planning operation even though the plan is not yet complete.
In Terraform 1.7 we'll begin phasing out the legacy credential chain evaluation order
by defaulting use_legacy_workflow to false and deprecating the argument. This will
bring the default behavior into alignment with the AWS SDKs and CLI. Practitioners
can still preserve the legacy behavior by setting this argument to `true`. In Terraform
1.8 this argument will be removed, and the S3 backend will always use the default
credential chain evaluation order from the AWS SDK for Go.
Unless a user specifically requests a real operation graph using the
-type option, we'll by default present a simplified graph which only
represents the relationships between resources, since resources are the
main side-effects and so the ordering of these is more interesting than
the ordering of Terraform's internal implementation details.
