Provider is not misled into thinking. Terraform may be misled into thinking that all of the managed objects have been deleted . So, Terraform removes all of the tracked objects from the state file.
This paragraph is trying to say that try only works for dynamic errors and
not for errors that are _not_ based on dynamic decision-making in
expressions.
I'm not sure if this typo was always here or if it was mistakenly "corrected"
at some point, but either way the word "probably" changes the meaning
of this sentence entirely, making it seem like Terraform is hedging
the likelihood of a problem rather than checking exactly for one.
Previously we would only ever add new lock entries or update existing
ones. However, it's possible that over time a module may _cease_ using
a particular provider, at which point we ought to remove it from the lock
file so that operations won't fail when seeing that the provider cache
directory is inconsistent with the lock file.
Now the provider installer (EnsureProviderVersions) will remove any lock
file entries that relate to providers not included in the given
requirements, which therefore makes the resulting lock file properly match
the set of packages the installer wrote into the cache.
This does potentially mean that someone could inadvertently defeat the
lock by removing a provider dependency, running "terraform init", then
undoing that removal, and finally running "terraform init" again. However,
that seems relatively unlikely compared to the likelihood of removing
a provider and keeping it removed, and in the event it _did_ happen the
changes to the lock entry for that provider would be visible in the diff
of the provider lock file as usual, and so could be noticed in code
review just as for any other change to dependencies.
This makes it match some incoming links we have elsewhere, but also it
makes the heading a bit more consice because "module" isn't really adding
anything here anyway: input variables are _always_ in modules.
We late-reorganized this into the "Module Development" subsection, but
forgot to update the actual link in the navbar, so it was still linking
to its old location.
Since this is only a minor release there isn't any super-significant
upgrade guide content this time, but I've used this page to elaborate on
some of the upgrade notes already recorded in the Terraform Changelog, to
give additional context if needed to the hopefully-small number of users
that these changes will directly effect during upgrading.
As explained in the changes: The 'enhanced' backend terminology, which
only truly pertains to the 'remote' backend with a single API (Terraform
Cloud/Enterprise's), has been found to be a confusing vestige which need
only be explained in the context of the 'remote' backend.
These changes reorient the explanation(s) of backends to pertain more
directly to their primary purpose, which is storage of state snapshots
(and not implementing operations).
That Terraform operations are still _implemented_ by the literal
`Backend` and `Enhanced` interfaces is inconsequential a user of
Terraform, an internal detail.
Apologies for not creating an issue first but it seemed like a simple docs change.
`apt install terraform` requires the `apt update` before terraform can be installed.
The HashiCorp APT server supports several distro releases that were not in this list,
leading to a false impression that they aren't supported.
Note, Ubuntu has a new release twice a year, so periodic maintenance
is needed here.
The `root_module.resources[].sensitive_values` key in the example output was incorrectly named and clashed with the regular `root_module.resources[].values` key.
Laura Pacilio