mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-02-18 22:00:36 -05:00
4d665a0091
* Initial renaming, rewriting and cleaning up wave for the CLI docs. Signed-off-by: Jakub Martin <kubam@spacelift.io> * More renaming. Signed-off-by: Jakub Martin <kubam@spacelift.io> * More renaming. Signed-off-by: Jakub Martin <kubam@spacelift.io> * More renaming. Signed-off-by: Jakub Martin <kubam@spacelift.io> * Remove tutorial references. Signed-off-by: Jakub Martin <kubam@spacelift.io> * Post-review fixes. Signed-off-by: Jakub Martin <kubam@spacelift.io> --------- Signed-off-by: Jakub Martin <kubam@spacelift.io>
64 lines
2.6 KiB
Plaintext
64 lines
2.6 KiB
Plaintext
---
|
|
page_title: Forcing Re-creation of Resources - OpenTF CLI
|
|
description: Commands that allow you to destroy and re-create resources manually.
|
|
---
|
|
|
|
# Forcing Re-creation of Resources
|
|
|
|
During planning, by default OpenTF retrieves the latest state of each
|
|
existing object and compares it with the current configuration, planning
|
|
actions only against objects whose current state does not match the
|
|
configuration.
|
|
|
|
However, in some cases a remote object may become damaged or degraded in a
|
|
way that OpenTF cannot automatically detect. For example, if software
|
|
running inside a virtual machine crashes but the virtual machine itself is
|
|
still running then OpenTF will typically have no way to detect and respond
|
|
to the problem, because OpenTF only directly manages the machine as a whole.
|
|
|
|
If you know that an object is damaged, or if you want to force OpenTF to
|
|
replace it for any other reason, you can override OpenTF's default behavior
|
|
using [the `-replace=...` planning option](/opentf/cli/commands/plan#replace-address)
|
|
when you run either `opentf plan` or `opentf apply`:
|
|
|
|
```shellsession
|
|
$ opentf apply -replace="aws_instance.example"
|
|
# ...
|
|
|
|
# aws_instance.example will be replaced, as requested
|
|
-/+ resource "aws_instance" "example" {
|
|
# ...
|
|
}
|
|
```
|
|
|
|
## The "tainted" status
|
|
|
|
Sometimes OpenTF is able to infer automatically that an object is in an
|
|
incomplete or degraded state. For example, if creation of a complex object
|
|
fails in such a way that parts of it already exist in the remote system, or
|
|
if object creation succeeded but a provisioner step subsequently failed,
|
|
OpenTF must remember that the object exists but may not be fully-functional.
|
|
|
|
OpenTF represents this situation by marking an object in the state as
|
|
"tainted". When an object is marked with this status, the next plan will force
|
|
replacing that object in a similar way to if you had specified that object's
|
|
address using `-replace=...` as described above.
|
|
|
|
```
|
|
# aws_instance.example is tainted, so it must be replaced
|
|
-/+ resource "aws_instance" "example" {
|
|
# ...
|
|
}
|
|
```
|
|
|
|
If OpenTF has marked an object as tainted but you consider it to be working
|
|
correctly and do not want to replace it, you can override OpenTF's
|
|
determination using [the `opentf untaint` command](/opentf/cli/commands/untaint),
|
|
after which OpenTF will consider the object to be ready for use by any
|
|
downstream resource declarations.
|
|
|
|
You can also _force_ OpenTF to mark a particular object as tainted using
|
|
[the `opentf taint` command](/opentf/cli/commands/taint), but that approach is
|
|
deprecated in favor of the `-replace=...` option, which avoids the need to
|
|
create an interim state snapshot with a tainted object.
|