mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-02-16 16:00:37 -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>
46 lines
2.1 KiB
Plaintext
46 lines
2.1 KiB
Plaintext
---
|
|
page_title: Moving Resources - OpenTF CLI
|
|
description: >-
|
|
Commands that allow you to manage the way that resources are tracked in state.
|
|
They are helpful when you move or change resources.
|
|
---
|
|
|
|
# Moving Resources
|
|
|
|
OpenTF's state associates each real-world object with a configured resource
|
|
at a specific [resource address](/opentf/cli/state/resource-addressing). This
|
|
is seamless when changing a resource's attributes, but OpenTF will lose track
|
|
of a resource if you change its name, move it to a different module, or change
|
|
its provider.
|
|
|
|
Usually that's fine: OpenTF will destroy the old resource, replace it with a
|
|
new one (using the new resource address), and update any resources that rely on
|
|
its attributes.
|
|
|
|
In cases where it's important to preserve an existing infrastructure object, you
|
|
can explicitly tell OpenTF to associate it with a different configured
|
|
resource.
|
|
|
|
For most cases we recommend using
|
|
[the OpenTF language's refactoring features](/opentf/language/modules/develop/refactoring)
|
|
to document in your module exactly how the resource names have changed over
|
|
time. OpenTF reacts to this information automatically during planning, so users of your module do not need to take any unusual extra steps.
|
|
|
|
There are some other situations which require explicit state modifications,
|
|
though. For those, consider the following OpenTF commands:
|
|
|
|
- [The `opentf state mv` command](/opentf/cli/commands/state/mv) changes
|
|
which resource address in your configuration is associated with a particular
|
|
real-world object. Use this to preserve an object when renaming a resource, or
|
|
when moving a resource into or out of a child module.
|
|
|
|
- [The `opentf state rm` command](/opentf/cli/commands/state/rm) tells
|
|
OpenTF to stop managing a resource as part of the current working directory
|
|
and workspace, _without_ destroying the corresponding real-world object. (You
|
|
can later use `opentf import` to start managing that resource in a
|
|
different workspace or a different OpenTF configuration.)
|
|
|
|
- [The `opentf state replace-provider` command](/opentf/cli/commands/state/replace-provider)
|
|
transfers existing resources to a new provider without requiring them to be
|
|
re-created.
|