terraform/command/state_mv.go

510 lines
16 KiB
Go
Raw Normal View History

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"
"github.com/hashicorp/terraform/addrs"
2019-01-08 14:57:52 +01:00
"github.com/hashicorp/terraform/command/clistate"
"github.com/hashicorp/terraform/states"
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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 {
args = c.Meta.process(args)
// We create two metas to track the two states
var backupPathOut, statePathOut string
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")
cmdFlags.BoolVar(&dryRun, "dry-run", false, "dry run")
cmdFlags.StringVar(&c.backupPath, "backup", "-", "backup")
cmdFlags.StringVar(&backupPathOut, "backup-out", "-", "backup")
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")
cmdFlags.StringVar(&statePathOut, "state-out", "", "path")
2016-04-12 20:44:12 +02:00
if err := cmdFlags.Parse(args); err != nil {
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
}
// Read the from state
stateFromMgr, err := c.State()
2016-04-12 20:44:12 +02:00
if err != nil {
c.Ui.Error(fmt.Sprintf(errStateLoadingState, err))
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)
}
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
}
stateFrom := stateFromMgr.State()
if stateFrom == nil {
2016-04-12 20:44:12 +02:00
c.Ui.Error(fmt.Sprintf(errStateNotFound))
return 1
}
// Read the destination state
stateToMgr := stateFromMgr
stateTo := stateFrom
if statePathOut != "" {
c.statePath = statePathOut
c.backupPath = backupPathOut
stateToMgr, err = c.State()
if err != nil {
c.Ui.Error(fmt.Sprintf(errStateLoadingState, err))
return 1
}
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)
}
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
}
stateTo = stateToMgr.State()
if stateTo == nil {
stateTo = states.NewState()
}
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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
}
2016-04-12 20:44:12 +02:00
prefix := "Move"
if dryRun {
prefix = "Would move"
}
2016-04-12 20:44:12 +02:00
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
const msgInvalidSource = "Invalid source address"
const msgInvalidTarget = "Invalid target address"
var moved int
ssFrom := stateFrom.SyncWrapper()
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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) {
case addrs.ModuleInstance:
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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,
fmt.Sprintf("Cannot move %s to %s: the target must also be a module.", addrFrom, addrTo),
))
c.showDiagnostics(diags)
return 1
}
2016-04-12 20:44:12 +02:00
if len(search) < len(addrFrom) {
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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
}
2016-04-12 20:44:12 +02:00
if stateTo.Module(addrTo) != nil {
c.Ui.Error(fmt.Sprintf(errStateMv, "destination module already exists"))
return 1
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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
}
moved++
c.Ui.Output(fmt.Sprintf("%s %q to %q", prefix, addrFrom.String(), addrTo.String()))
if !dryRun {
ssFrom.RemoveModule(addrFrom)
// Update the address before adding it to the state.
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
ms.Addr = addrTo
stateTo.Modules[addrTo.String()] = ms
}
case addrs.AbsResource:
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
addrTo, ok := destAddr.(addrs.AbsResource)
if !ok {
diags = diags.Append(tfdiags.Sourceless(
tfdiags.Error,
msgInvalidTarget,
fmt.Sprintf("Cannot move %s to %s: the target must also be a whole resource.", addrFrom, addrTo),
))
c.showDiagnostics(diags)
return 1
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
diags = diags.Append(c.validateResourceMove(addrFrom, addrTo))
if stateTo.Resource(addrTo) != nil {
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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)
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.
rs.Addr = addrTo
stateTo.EnsureModule(addrTo.Module).Resources[addrTo.Resource.String()] = rs
}
case addrs.AbsResourceInstance:
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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,
fmt.Sprintf("Cannot move %s to %s: the target must also be a resource instance.", addrFrom, addrTo),
))
c.showDiagnostics(diags)
return 1
}
addrTo = ra.Instance(addrs.NoKey)
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
diags = diags.Append(c.validateResourceMove(addrFrom.ContainingResource(), addrTo.ContainingResource()))
if stateTo.Module(addrTo.Module) == nil {
// moving something to a mew module, so we need to ensure it exists
stateTo.EnsureModule(addrTo.Module)
}
if stateTo.ResourceInstance(addrTo) != nil {
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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)
return 1
}
moved++
c.Ui.Output(fmt.Sprintf("%s %q to %q", prefix, addrFrom.String(), args[1]))
if !dryRun {
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
fromResourceAddr := addrFrom.ContainingResource()
fromResource := ssFrom.Resource(fromResourceAddr)
fromProviderAddr := fromResource.ProviderConfig
ssFrom.ForgetResourceInstanceAll(addrFrom)
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
ssFrom.RemoveResourceIfEmpty(fromResourceAddr)
rs := stateTo.Resource(addrTo.ContainingResource())
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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
// address covers both). If there's an index in the
// target then allow creating the new instance here.
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
resourceAddr := addrTo.ContainingResource()
stateTo.SyncWrapper().SetResourceProvider(
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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),
))
}
// 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
}
}
}
}
}
}
if dryRun {
if moved == 0 {
c.Ui.Output("Would have moved nothing.")
}
return 0 // This is as far as we go in dry-run mode
}
// 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
}
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
c.showDiagnostics(diags)
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
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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.
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)
}
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
default:
ret = append(ret, matched)
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
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-04-12 20:44:12 +02:00
func (c *StateMvCommand) Help() string {
helpText := `
Usage: terraform state mv [options] SOURCE DESTINATION
2016-04-12 20:44:12 +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
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
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
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.
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
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
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.
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.
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=0s Duration to retry a state lock.
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
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
this isn't specified, the source state file will be
used. This can be a new or existing path.
-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"
}
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.`