2016-04-12 20:44:12 +02:00
package command
import (
2019-01-08 14:57:52 +01:00
"context"
2016-04-12 20:44:12 +02:00
"fmt"
"strings"
2018-10-25 15:41:00 +02:00
"github.com/hashicorp/terraform/addrs"
2019-01-08 14:57:52 +01:00
"github.com/hashicorp/terraform/command/clistate"
terraform: Ugly huge change to weave in new State and Plan types
Due to how often the state and plan types are referenced throughout
Terraform, there isn't a great way to switch them out gradually. As a
consequence, this huge commit gets us from the old world to a _compilable_
new world, but still has a large number of known test failures due to
key functionality being stubbed out.
The stubs here are for anything that interacts with providers, since we
now need to do the follow-up work to similarly replace the old
terraform.ResourceProvider interface with its replacement in the new
"providers" package. That work, along with work to fix the remaining
failing tests, will follow in subsequent commits.
The aim here was to replace all references to terraform.State and its
downstream types with states.State, terraform.Plan with plans.Plan,
state.State with statemgr.State, and switch to the new implementations of
the state and plan file formats. However, due to the number of times those
types are used, this also ended up affecting numerous other parts of core
such as terraform.Hook, the backend.Backend interface, and most of the CLI
commands.
Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize
in advance to the person who inevitably just found this huge commit while
spelunking through the commit history.
2018-08-14 23:24:45 +02:00
"github.com/hashicorp/terraform/states"
2019-03-16 03:51:26 +01:00
"github.com/hashicorp/terraform/tfdiags"
2016-04-12 20:44:12 +02:00
"github.com/mitchellh/cli"
)
// StateMvCommand is a Command implementation that shows a single resource.
type StateMvCommand struct {
StateMeta
}
func ( c * StateMvCommand ) Run ( args [ ] string ) int {
2020-04-01 21:01:08 +02:00
args = c . Meta . process ( args )
2016-04-12 23:17:59 +02:00
// We create two metas to track the two states
2017-07-26 19:08:09 +02:00
var backupPathOut , statePathOut string
2018-10-25 15:41:00 +02:00
var dryRun bool
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
cmdFlags := c . Meta . ignoreRemoteVersionFlagSet ( "state mv" )
2018-10-25 15:41:00 +02:00
cmdFlags . BoolVar ( & dryRun , "dry-run" , false , "dry run" )
2017-07-26 19:08:09 +02:00
cmdFlags . StringVar ( & c . backupPath , "backup" , "-" , "backup" )
cmdFlags . StringVar ( & backupPathOut , "backup-out" , "-" , "backup" )
2018-11-21 15:35:27 +01:00
cmdFlags . BoolVar ( & c . Meta . stateLock , "lock" , true , "lock states" )
cmdFlags . DurationVar ( & c . Meta . stateLockTimeout , "lock-timeout" , 0 , "lock timeout" )
cmdFlags . StringVar ( & c . statePath , "state" , "" , "path" )
2017-07-26 19:08:09 +02:00
cmdFlags . StringVar ( & statePathOut , "state-out" , "" , "path" )
2016-04-12 20:44:12 +02:00
if err := cmdFlags . Parse ( args ) ; err != nil {
2019-08-16 14:31:21 +02:00
c . Ui . Error ( fmt . Sprintf ( "Error parsing command-line flags: %s\n" , err . Error ( ) ) )
return 1
2016-04-12 20:44:12 +02:00
}
args = cmdFlags . Args ( )
if len ( args ) != 2 {
c . Ui . Error ( "Exactly two arguments expected.\n" )
return cli . RunResultHelp
}
2016-04-12 23:17:59 +02:00
// Read the from state
2018-10-25 15:41:00 +02:00
stateFromMgr , err := c . State ( )
2016-04-12 20:44:12 +02:00
if err != nil {
c . Ui . Error ( fmt . Sprintf ( errStateLoadingState , err ) )
2017-07-27 20:10:52 +02:00
return 1
2016-04-12 20:44:12 +02:00
}
2019-01-08 14:57:52 +01:00
if c . stateLock {
stateLocker := clistate . NewLocker ( context . Background ( ) , c . stateLockTimeout , c . Ui , c . Colorize ( ) )
if err := stateLocker . Lock ( stateFromMgr , "state-mv" ) ; err != nil {
c . Ui . Error ( fmt . Sprintf ( "Error locking source state: %s" , err ) )
return 1
}
defer stateLocker . Unlock ( nil )
}
2018-10-25 15:41:00 +02:00
if err := stateFromMgr . RefreshState ( ) ; err != nil {
2019-01-08 14:57:52 +01:00
c . Ui . Error ( fmt . Sprintf ( "Failed to refresh source state: %s" , err ) )
2016-04-12 20:44:12 +02:00
return 1
}
2018-10-25 15:41:00 +02:00
stateFrom := stateFromMgr . State ( )
if stateFrom == nil {
2020-12-01 18:34:50 +01:00
c . Ui . Error ( errStateNotFound )
2016-04-12 20:44:12 +02:00
return 1
}
2016-04-12 23:17:59 +02:00
// Read the destination state
2018-10-25 15:41:00 +02:00
stateToMgr := stateFromMgr
2016-04-12 23:17:59 +02:00
stateTo := stateFrom
2017-07-26 19:08:09 +02:00
if statePathOut != "" {
c . statePath = statePathOut
c . backupPath = backupPathOut
2018-10-25 15:41:00 +02:00
stateToMgr , err = c . State ( )
2016-04-12 23:17:59 +02:00
if err != nil {
c . Ui . Error ( fmt . Sprintf ( errStateLoadingState , err ) )
2017-07-27 20:10:52 +02:00
return 1
2016-04-12 23:17:59 +02:00
}
2019-01-08 14:57:52 +01:00
if c . stateLock {
stateLocker := clistate . NewLocker ( context . Background ( ) , c . stateLockTimeout , c . Ui , c . Colorize ( ) )
if err := stateLocker . Lock ( stateToMgr , "state-mv" ) ; err != nil {
c . Ui . Error ( fmt . Sprintf ( "Error locking destination state: %s" , err ) )
return 1
}
defer stateLocker . Unlock ( nil )
}
2018-10-25 15:41:00 +02:00
if err := stateToMgr . RefreshState ( ) ; err != nil {
2019-01-08 14:57:52 +01:00
c . Ui . Error ( fmt . Sprintf ( "Failed to refresh destination state: %s" , err ) )
2017-02-22 05:35:43 +01:00
return 1
}
2018-10-25 15:41:00 +02:00
stateTo = stateToMgr . State ( )
if stateTo == nil {
stateTo = states . NewState ( )
2016-04-12 23:17:59 +02:00
}
}
2019-03-16 03:51:26 +01:00
var diags tfdiags . Diagnostics
sourceAddr , moreDiags := c . lookupSingleStateObjectAddr ( stateFrom , args [ 0 ] )
diags = diags . Append ( moreDiags )
destAddr , moreDiags := c . lookupSingleStateObjectAddr ( stateFrom , args [ 1 ] )
diags = diags . Append ( moreDiags )
if diags . HasErrors ( ) {
c . showDiagnostics ( diags )
return 1
2018-10-25 15:41:00 +02:00
}
2016-04-12 20:44:12 +02:00
2018-10-25 15:41:00 +02:00
prefix := "Move"
if dryRun {
prefix = "Would move"
}
2016-04-12 20:44:12 +02:00
2019-03-16 03:51:26 +01:00
const msgInvalidSource = "Invalid source address"
const msgInvalidTarget = "Invalid target address"
2018-10-25 15:41:00 +02:00
var moved int
ssFrom := stateFrom . SyncWrapper ( )
2019-03-16 03:51:26 +01:00
sourceAddrs := c . sourceObjectAddrs ( stateFrom , sourceAddr )
if len ( sourceAddrs ) == 0 {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidSource ,
fmt . Sprintf ( "Cannot move %s: does not match anything in the current state." , sourceAddr ) ,
) )
}
for _ , rawAddrFrom := range sourceAddrs {
switch addrFrom := rawAddrFrom . ( type ) {
2018-10-25 15:41:00 +02:00
case addrs . ModuleInstance :
2019-03-16 03:51:26 +01:00
search := sourceAddr . ( addrs . ModuleInstance )
addrTo , ok := destAddr . ( addrs . ModuleInstance )
if ! ok {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidTarget ,
2021-01-12 18:59:28 +01:00
fmt . Sprintf ( "Cannot move %s to %s: the target must also be a module." , addrFrom , destAddr ) ,
2019-03-16 03:51:26 +01:00
) )
c . showDiagnostics ( diags )
2018-10-25 15:41:00 +02:00
return 1
}
2016-04-12 20:44:12 +02:00
2018-10-25 15:41:00 +02:00
if len ( search ) < len ( addrFrom ) {
2019-03-16 03:51:26 +01:00
n := make ( addrs . ModuleInstance , 0 , len ( addrTo ) + len ( addrFrom ) - len ( search ) )
n = append ( n , addrTo ... )
n = append ( n , addrFrom [ len ( search ) : ] ... )
addrTo = n
2018-10-25 15:41:00 +02:00
}
2016-04-12 20:44:12 +02:00
2018-10-25 15:41:00 +02:00
if stateTo . Module ( addrTo ) != nil {
c . Ui . Error ( fmt . Sprintf ( errStateMv , "destination module already exists" ) )
return 1
}
2016-04-12 23:17:59 +02:00
2019-03-16 03:51:26 +01:00
ms := ssFrom . Module ( addrFrom )
if ms == nil {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidSource ,
fmt . Sprintf ( "The current state does not contain %s." , addrFrom ) ,
) )
c . showDiagnostics ( diags )
return 1
}
2018-10-25 15:41:00 +02:00
moved ++
c . Ui . Output ( fmt . Sprintf ( "%s %q to %q" , prefix , addrFrom . String ( ) , addrTo . String ( ) ) )
if ! dryRun {
ssFrom . RemoveModule ( addrFrom )
terraform: Ugly huge change to weave in new State and Plan types
Due to how often the state and plan types are referenced throughout
Terraform, there isn't a great way to switch them out gradually. As a
consequence, this huge commit gets us from the old world to a _compilable_
new world, but still has a large number of known test failures due to
key functionality being stubbed out.
The stubs here are for anything that interacts with providers, since we
now need to do the follow-up work to similarly replace the old
terraform.ResourceProvider interface with its replacement in the new
"providers" package. That work, along with work to fix the remaining
failing tests, will follow in subsequent commits.
The aim here was to replace all references to terraform.State and its
downstream types with states.State, terraform.Plan with plans.Plan,
state.State with statemgr.State, and switch to the new implementations of
the state and plan file formats. However, due to the number of times those
types are used, this also ended up affecting numerous other parts of core
such as terraform.Hook, the backend.Backend interface, and most of the CLI
commands.
Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize
in advance to the person who inevitably just found this huge commit while
spelunking through the commit history.
2018-08-14 23:24:45 +02:00
2018-10-25 15:41:00 +02:00
// Update the address before adding it to the state.
2019-03-16 03:51:26 +01:00
ms . Addr = addrTo
stateTo . Modules [ addrTo . String ( ) ] = ms
2018-10-25 15:41:00 +02:00
}
case addrs . AbsResource :
2019-03-16 03:51:26 +01:00
addrTo , ok := destAddr . ( addrs . AbsResource )
if ! ok {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidTarget ,
2021-01-12 19:21:25 +01:00
fmt . Sprintf ( "Cannot move %s to %s: the source is a whole resource (not a resource instance) so the target must also be a whole resource." , addrFrom , destAddr ) ,
2019-03-16 03:51:26 +01:00
) )
c . showDiagnostics ( diags )
2018-10-25 15:41:00 +02:00
return 1
}
2019-03-16 03:51:26 +01:00
diags = diags . Append ( c . validateResourceMove ( addrFrom , addrTo ) )
2020-07-08 23:09:58 +02:00
2018-10-25 15:41:00 +02:00
if stateTo . Resource ( addrTo ) != nil {
2019-03-16 03:51:26 +01:00
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidTarget ,
fmt . Sprintf ( "Cannot move to %s: there is already a resource at that address in the current state." , addrTo ) ,
) )
}
rs := ssFrom . Resource ( addrFrom )
if rs == nil {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidSource ,
fmt . Sprintf ( "The current state does not contain %s." , addrFrom ) ,
) )
}
if diags . HasErrors ( ) {
c . showDiagnostics ( diags )
2018-10-25 15:41:00 +02:00
return 1
}
moved ++
c . Ui . Output ( fmt . Sprintf ( "%s %q to %q" , prefix , addrFrom . String ( ) , addrTo . String ( ) ) )
if ! dryRun {
ssFrom . RemoveResource ( addrFrom )
// Update the address before adding it to the state.
2020-03-16 21:50:48 +01:00
rs . Addr = addrTo
2020-07-08 23:09:58 +02:00
stateTo . EnsureModule ( addrTo . Module ) . Resources [ addrTo . Resource . String ( ) ] = rs
2018-10-25 15:41:00 +02:00
}
case addrs . AbsResourceInstance :
2019-03-16 03:51:26 +01:00
addrTo , ok := destAddr . ( addrs . AbsResourceInstance )
if ! ok {
ra , ok := destAddr . ( addrs . AbsResource )
if ! ok {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidTarget ,
2021-01-12 18:59:28 +01:00
fmt . Sprintf ( "Cannot move %s to %s: the target must also be a resource instance." , addrFrom , destAddr ) ,
2019-03-16 03:51:26 +01:00
) )
c . showDiagnostics ( diags )
return 1
}
addrTo = ra . Instance ( addrs . NoKey )
2018-10-25 15:41:00 +02:00
}
2019-03-16 03:51:26 +01:00
diags = diags . Append ( c . validateResourceMove ( addrFrom . ContainingResource ( ) , addrTo . ContainingResource ( ) ) )
2018-10-25 15:41:00 +02:00
if stateTo . Module ( addrTo . Module ) == nil {
2019-08-02 00:54:09 +02:00
// moving something to a mew module, so we need to ensure it exists
stateTo . EnsureModule ( addrTo . Module )
2018-10-25 15:41:00 +02:00
}
if stateTo . ResourceInstance ( addrTo ) != nil {
2019-03-16 03:51:26 +01:00
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidTarget ,
fmt . Sprintf ( "Cannot move to %s: there is already a resource instance at that address in the current state." , addrTo ) ,
) )
}
is := ssFrom . ResourceInstance ( addrFrom )
if is == nil {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidSource ,
fmt . Sprintf ( "The current state does not contain %s." , addrFrom ) ,
) )
}
if diags . HasErrors ( ) {
c . showDiagnostics ( diags )
2018-10-25 15:41:00 +02:00
return 1
}
moved ++
c . Ui . Output ( fmt . Sprintf ( "%s %q to %q" , prefix , addrFrom . String ( ) , args [ 1 ] ) )
if ! dryRun {
2019-03-16 03:51:26 +01:00
fromResourceAddr := addrFrom . ContainingResource ( )
2019-12-05 22:06:25 +01:00
fromResource := ssFrom . Resource ( fromResourceAddr )
fromProviderAddr := fromResource . ProviderConfig
2018-10-25 15:41:00 +02:00
ssFrom . ForgetResourceInstanceAll ( addrFrom )
2019-03-16 03:51:26 +01:00
ssFrom . RemoveResourceIfEmpty ( fromResourceAddr )
2018-10-25 15:41:00 +02:00
rs := stateTo . Resource ( addrTo . ContainingResource ( ) )
2019-03-16 03:51:26 +01:00
if rs == nil {
// If we're moving to an address without an index then that
// suggests the user's intent is to establish both the
// resource and the instance at the same time (since the
2019-12-05 22:06:25 +01:00
// address covers both). If there's an index in the
2020-03-02 20:45:03 +01:00
// target then allow creating the new instance here.
2019-03-16 03:51:26 +01:00
resourceAddr := addrTo . ContainingResource ( )
2020-04-25 03:52:05 +02:00
stateTo . SyncWrapper ( ) . SetResourceProvider (
2019-03-16 03:51:26 +01:00
resourceAddr ,
fromProviderAddr , // in this case, we bring the provider along as if we were moving the whole resource
)
rs = stateTo . Resource ( resourceAddr )
}
rs . Instances [ addrTo . Resource . Key ] = is
2018-10-25 15:41:00 +02:00
}
2019-03-16 03:51:26 +01:00
default :
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidSource ,
fmt . Sprintf ( "Cannot move %s: Terraform doesn't know how to move this object." , rawAddrFrom ) ,
) )
2018-10-25 15:41:00 +02:00
}
2020-01-04 14:29:25 +01:00
// Look for any dependencies that may be effected and
// remove them to ensure they are recreated in full.
for _ , mod := range stateTo . Modules {
for _ , res := range mod . Resources {
for _ , ins := range res . Instances {
if ins . Current == nil {
continue
}
for _ , dep := range ins . Current . Dependencies {
// check both directions here, since we may be moving
// an instance which is in a resource, or a module
// which can contain a resource.
if dep . TargetContains ( rawAddrFrom ) || rawAddrFrom . TargetContains ( dep ) {
ins . Current . Dependencies = nil
break
}
}
}
}
}
2018-10-25 15:41:00 +02:00
}
if dryRun {
if moved == 0 {
c . Ui . Output ( "Would have moved nothing." )
terraform: Ugly huge change to weave in new State and Plan types
Due to how often the state and plan types are referenced throughout
Terraform, there isn't a great way to switch them out gradually. As a
consequence, this huge commit gets us from the old world to a _compilable_
new world, but still has a large number of known test failures due to
key functionality being stubbed out.
The stubs here are for anything that interacts with providers, since we
now need to do the follow-up work to similarly replace the old
terraform.ResourceProvider interface with its replacement in the new
"providers" package. That work, along with work to fix the remaining
failing tests, will follow in subsequent commits.
The aim here was to replace all references to terraform.State and its
downstream types with states.State, terraform.Plan with plans.Plan,
state.State with statemgr.State, and switch to the new implementations of
the state and plan file formats. However, due to the number of times those
types are used, this also ended up affecting numerous other parts of core
such as terraform.Hook, the backend.Backend interface, and most of the CLI
commands.
Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize
in advance to the person who inevitably just found this huge commit while
spelunking through the commit history.
2018-08-14 23:24:45 +02:00
}
2018-10-25 15:41:00 +02:00
return 0 // This is as far as we go in dry-run mode
}
2016-04-12 23:17:59 +02:00
2018-10-25 15:41:00 +02:00
// Write the new state
if err := stateToMgr . WriteState ( stateTo ) ; err != nil {
c . Ui . Error ( fmt . Sprintf ( errStateRmPersist , err ) )
return 1
}
if err := stateToMgr . PersistState ( ) ; err != nil {
c . Ui . Error ( fmt . Sprintf ( errStateRmPersist , err ) )
return 1
}
// Write the old state if it is different
if stateTo != stateFrom {
if err := stateFromMgr . WriteState ( stateFrom ) ; err != nil {
c . Ui . Error ( fmt . Sprintf ( errStateRmPersist , err ) )
return 1
}
if err := stateFromMgr . PersistState ( ) ; err != nil {
c . Ui . Error ( fmt . Sprintf ( errStateRmPersist , err ) )
return 1
}
}
2019-03-16 03:51:26 +01:00
c . showDiagnostics ( diags )
2018-10-25 15:41:00 +02:00
if moved == 0 {
c . Ui . Output ( "No matching objects found." )
} else {
c . Ui . Output ( fmt . Sprintf ( "Successfully moved %d object(s)." , moved ) )
}
2016-04-12 20:44:12 +02:00
return 0
}
2019-03-16 03:51:26 +01:00
// sourceObjectAddrs takes a single source object address and expands it to
// potentially multiple objects that need to be handled within it.
//
// In particular, this handles the case where a module is requested directly:
// if it has any child modules, then they must also be moved. It also resolves
// the ambiguity that an index-less resource address could either be a resource
// address or a resource instance address, by making a decision about which
// is intended based on the current state of the resource in question.
func ( c * StateMvCommand ) sourceObjectAddrs ( state * states . State , matched addrs . Targetable ) [ ] addrs . Targetable {
var ret [ ] addrs . Targetable
switch addr := matched . ( type ) {
case addrs . ModuleInstance :
for _ , mod := range state . Modules {
if len ( mod . Addr ) < len ( addr ) {
continue // can't possibly be our selection or a child of it
2016-08-18 23:39:07 +02:00
}
2019-03-16 03:51:26 +01:00
if ! mod . Addr [ : len ( addr ) ] . Equal ( addr ) {
continue
}
ret = append ( ret , mod . Addr )
}
case addrs . AbsResource :
// If this refers to a resource without "count" or "for_each" set then
// we'll assume the user intended it to be a resource instance
// address instead, to allow for requests like this:
// terraform state mv aws_instance.foo aws_instance.bar[1]
// That wouldn't be allowed if aws_instance.foo had multiple instances
// since we can't move multiple instances into one.
2020-04-25 03:52:05 +02:00
if rs := state . Resource ( addr ) ; rs != nil {
if _ , ok := rs . Instances [ addrs . NoKey ] ; ok {
ret = append ( ret , addr . Instance ( addrs . NoKey ) )
} else {
ret = append ( ret , addr )
}
2016-08-18 23:39:07 +02:00
}
2019-03-16 03:51:26 +01:00
default :
ret = append ( ret , matched )
2016-08-18 23:39:07 +02:00
}
2018-10-25 15:41:00 +02:00
2019-03-16 03:51:26 +01:00
return ret
}
func ( c * StateMvCommand ) validateResourceMove ( addrFrom , addrTo addrs . AbsResource ) tfdiags . Diagnostics {
const msgInvalidRequest = "Invalid state move request"
var diags tfdiags . Diagnostics
if addrFrom . Resource . Mode != addrTo . Resource . Mode {
switch addrFrom . Resource . Mode {
case addrs . ManagedResourceMode :
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidRequest ,
fmt . Sprintf ( "Cannot move %s to %s: a managed resource can be moved only to another managed resource address." , addrFrom , addrTo ) ,
) )
case addrs . DataResourceMode :
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidRequest ,
fmt . Sprintf ( "Cannot move %s to %s: a data resource can be moved only to another data resource address." , addrFrom , addrTo ) ,
) )
default :
// In case a new mode is added in future, this unhelpful error is better than nothing.
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidRequest ,
fmt . Sprintf ( "Cannot move %s to %s: cannot change resource mode." , addrFrom , addrTo ) ,
) )
}
}
if addrFrom . Resource . Type != addrTo . Resource . Type {
diags = diags . Append ( tfdiags . Sourceless (
tfdiags . Error ,
msgInvalidRequest ,
fmt . Sprintf ( "Cannot move %s to %s: resource types don't match." , addrFrom , addrTo ) ,
) )
}
return diags
2016-08-18 23:39:07 +02:00
}
2016-04-12 20:44:12 +02:00
func ( c * StateMvCommand ) Help ( ) string {
helpText := `
2017-07-27 22:03:21 +02:00
Usage : terraform state mv [ options ] SOURCE DESTINATION
2016-04-12 20:44:12 +02:00
2017-07-27 22:03:21 +02:00
This command will move an item matched by the address given to the
destination address . This command can also move to a destination address
in a completely different state file .
2016-04-12 20:44:12 +02:00
2017-07-27 22:03:21 +02:00
This can be used for simple resource renaming , moving items to and from
a module , moving entire modules , and more . And because this command can also
move data to a completely new state , it can also be used for refactoring
one configuration into multiple separately managed Terraform configurations .
2016-04-12 20:44:12 +02:00
2017-07-27 22:03:21 +02:00
This command will output a backup copy of the state prior to saving any
changes . The backup cannot be disabled . Due to the destructive nature
of this command , backups are required .
2016-04-12 20:44:12 +02:00
2017-07-27 22:03:21 +02:00
If you ' re moving an item to a different state file , a backup will be created
for each state file .
2016-04-12 20:44:12 +02:00
Options :
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- dry - run If set , prints out what would ' ve been moved but doesn ' t
actually move anything .
2018-10-25 15:41:00 +02:00
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- backup = PATH Path where Terraform should write the backup for the
2021-01-26 17:24:28 +01:00
original state . This can ' t be disabled . If not set ,
Terraform will write it to the same path as the
statefile with a ".backup" extension .
2016-04-12 20:44:12 +02:00
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- backup - out = PATH Path where Terraform should write the backup for the
2021-01-26 17:24:28 +01:00
destination state . This can ' t be disabled . If not
set , Terraform will write it to the same path as the
destination state file with a backup extension . This
only needs to be specified if - state - out is set to a
different path than - state .
2016-04-12 23:17:59 +02:00
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- lock = true Lock the state files when locking is supported .
2018-11-21 15:35:27 +01:00
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- lock - timeout = 0 s Duration to retry a state lock .
2018-11-21 15:35:27 +01:00
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- state = PATH Path to the source state file . Defaults to the
2021-01-26 17:24:28 +01:00
configured backend , or "terraform.tfstate"
2016-04-12 20:44:12 +02:00
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- state - out = PATH Path to the destination state file to write to . If
2021-01-26 17:24:28 +01:00
this isn ' t specified , the source state file will be
used . This can be a new or existing path .
backend: Validate remote backend Terraform version
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.
2020-11-13 22:43:56 +01:00
- ignore - remote - version Continue even if remote and local Terraform versions
differ . This may result in an unusable workspace , and
should be used with extreme caution .
2016-04-12 20:44:12 +02:00
`
return strings . TrimSpace ( helpText )
}
func ( c * StateMvCommand ) Synopsis ( ) string {
return "Move an item in the state"
}
2018-10-25 15:41:00 +02:00
const errStateMv = ` Error moving state : % s
2016-04-12 20:44:12 +02:00
Please ensure your addresses and state paths are valid . No
state was persisted . Your existing states are untouched . `