Update note and add learn call out
This commit is contained in:
parent
fc7358611c
commit
529a2c34df
|
@ -8,12 +8,9 @@ description: |-
|
|||
|
||||
# Refactoring
|
||||
|
||||
~> **Note:** Explicit refactoring declarations with `moved` blocks will work
|
||||
only in Terraform v1.1 and later. When working with earlier Terraform versions,
|
||||
or for refactoring actions too complex to express as `moved` blocks, you could
|
||||
use
|
||||
[the `terraform state mv` CLI command](/docs/cli/commands/state/mv.html)
|
||||
as a separate step instead.
|
||||
-> **Note:** Explicit refactoring declarations with `moved` blocks is available in Terraform v1.1 and later. For earlier Terraform versions or for refactoring actions too complex to express as `moved` blocks, you can
|
||||
use the [`terraform state mv` CLI command](/docs/cli/commands/state/mv.html)
|
||||
as a separate step.
|
||||
|
||||
In shared modules and long-lived configurations, you may eventually outgrow
|
||||
your initial module structure and resource names. For example, you might decide
|
||||
|
@ -29,6 +26,8 @@ When you add `moved` blocks in your configuration to record where you've
|
|||
historically moved or renamed an object, Terraform treats an existing object at
|
||||
the old address as if it now belongs to the new address.
|
||||
|
||||
> **Hands On:** Try the [Use Configuration to Move Resources](https://learn.hashicorp.com/tutorials/terraform/move-config) tutorial on HashiCorp Learn.
|
||||
|
||||
## `moved` Block Syntax
|
||||
|
||||
A `moved` block expects no labels and contains only `from` and `to` arguments:
|
||||
|
|
Loading…
Reference in New Issue