c5c1f31db3
When using the enhanced remote backend, a subset of all Terraform operations are supported. Of these, only plan and apply can be executed on the remote infrastructure (e.g. Terraform Cloud). Other operations run locally and use the remote backend for state storage. This causes problems when the local version of Terraform does not match the configured version from the remote workspace. If the two versions are incompatible, an `import` or `state mv` operation can cause the remote workspace to be unusable until a manual fix is applied. To prevent this from happening accidentally, this commit introduces a check that the local Terraform version and the configured remote workspace Terraform version are compatible. This check is skipped for commands which do not write state, and can also be disabled by the use of a new command-line flag, `-ignore-remote-version`. Terraform version compatibility is defined as: - For all releases before 0.14.0, local must exactly equal remote, as two different versions cannot share state; - 0.14.0 to 1.0.x are compatible, as we will not change the state version number until at least Terraform 1.1.0; - Versions after 1.1.0 must have the same major and minor versions, as we will not change the state version number in a patch release. If the two versions are incompatible, a diagnostic is displayed, advising that the error can be suppressed with `-ignore-remote-version`. When this flag is used, the diagnostic is still displayed, but as a warning instead of an error. Commands which will not write state can assert this fact by calling the helper `meta.ignoreRemoteBackendVersionConflict`, which will disable the checks. Those which can write state should instead call the helper `meta.remoteBackendVersionCheck`, which will return diagnostics for display. In addition to these explicit paths for managing the version check, we have an implicit check in the remote backend's state manager initialization method. Both of the above helpers will disable this check. This fallback is in place to ensure that future code paths which access state cannot accidentally skip the remote version check.
2.7 KiB
layout, page_title, sidebar_current, description
| layout | page_title | sidebar_current | description |
|---|---|---|---|
| docs | Command: untaint | docs-commands-untaint | The `terraform untaint` command manually unmarks a Terraform-managed resource as tainted, restoring it as the primary instance in the state. |
Command: untaint
The terraform untaint command manually unmarks a Terraform-managed resource
as tainted, restoring it as the primary instance in the state. This reverses
either a manual terraform taint or the result of provisioners failing on a
resource.
This command will not modify infrastructure, but does modify the state file in order to unmark a resource as tainted.
~> NOTE on Tainted Indexes: In certain edge cases, more than one tainted
instance can be present for a single resource. When this happens, you need to specify the index after the resources, e.g. my-resource-example[2]. You can use the terraform show command to inspect the state and
determine which index holds the instance you'd like to restore. In the vast
majority of cases, there will only be one tainted instance, and the -index
flag can be omitted.
Usage
Usage: terraform untaint [options] name
The name argument is the name of the resource to mark as untainted. The
format of this argument is TYPE.NAME, such as aws_instance.foo.
The command-line flags are all optional (with the exception of -index in
certain cases, see above note). The list of available flags are:
-
-allow-missing- If specified, the command will succeed (exit code 0) even if the resource is missing. The command can still error, but only in critically erroneous cases. -
-backup=path- Path to the backup file. Defaults to-state-outwith the ".backup" extension. Disabled by setting to "-". -
-lock=true- Lock the state file when locking is supported. -
-lock-timeout=0s- Duration to retry a state lock. -
-module=path- The module path where the resource to untaint exists. By default this is the root path. Other modules can be specified by a period-separated list. Example: "foo" would reference the module "foo" but "foo.bar" would reference the "bar" module in the "foo" module. -
-no-color- Disables output with coloring -
-state=path- Path to read and write the state file to. Defaults to "terraform.tfstate". Ignored when remote state is used. -
-state-out=path- Path to write updated state file. By default, the-statepath will be used. Ignored when remote state is used. -
-ignore-remote-version- When using the enhanced remote backend with Terraform Cloud, continue even if remote and local Terraform versions differ. This may result in an unusable Terraform Cloud workspace, and should be used with extreme caution.