Commit Graph

41 Commits

Author SHA1 Message Date
Pam Selle 9371b60d71 More verbose error for whole resource move failure
When running state mv with a resource source, but the destination
fails, provide a hint that the source is a resource (not an instance)
in case the user means to address it this way
2021-01-12 13:21:25 -05:00
Pam Selle 52c77ba33e Print addresses in state mv errors
Using the addrTo after it has failed its check means <invalid>/no
address will be printed. Change this throughout, but particularly
add a test for the origin issue for this.
2021-01-12 13:05:01 -05:00
James Bardin 1c58c6ba48 command staticcheck 2020-12-02 13:59:19 -05:00
Alisdair McDiarmid c5c1f31db3 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-19 13:19:40 -05:00
Kristin Laemmert d2e999ba1f
remove unused code (#26503)
* remove unused code

I've removed the provider-specific code under registry, and unused nil
backend, and replaced a call to helper from backend/oss (the other
callers of that func are provisioners scheduled to be deprecated).

I also removed the Dockerfile, as our build process uses a different
file.

Finally I removed the examples directory, which had outdated examples
and links. There are better, actively maintained examples available.

* command: remove various unused bits

* test wasn't running

* backend: remove unused err
2020-10-07 11:00:06 -04:00
Alisdair McDiarmid 17e1c9dd05 command: Fix state mv for only resource in module
When moving a resource block with multiple instances to a new address
within the same module, we need to ensure that the target module is
present as late as possible. Otherwise, deleting the resource from the
original address triggers pruning, and the module is removed just before
we try to add the resource to it, which causes a crash.

Includes regression test which panics without this code change.
2020-08-11 11:54:35 -04:00
James Bardin 2bfaddcf57 fix state mv to work without EachMode
The only situation where `state mv` needs to understand the each mode is
when with resource addresses that may reference a single instance, or a
group of for_each or count instances. In this case we can differentiate
the two by checking the existence of the NoKey instance key.
2020-04-30 09:22:15 -04:00
Alisdair McDiarmid 67203dade8 command: Simplify Meta.process helper method
After some refactoring, this helper method had an unused argument (vars)
and an always-nil error return value. This commit cleans this up.
2020-04-01 15:01:08 -04:00
James Bardin a8b9547e0d fixup states.Resource change throughout packages 2020-03-16 16:50:48 -04:00
James Bardin 10d926904f state mv should always target instance each mode
When doing a state mv of an instance, the resulting each mode should
always be taken from the target address.
2020-03-02 14:45:03 -05:00
James Bardin 98c02ac114 remove stale dependencies on `state mv`
Clear any Dependencies if there is an entry matching a `state mv` from
address. While stale dependencies won't directly effect any current
operations, clearing the list will allow them to be recreated in their
entirety during refresh. This will help future releases that may rely
solely on the pre-calculated dependencies for destruction ordering.
2020-01-06 15:06:41 -05:00
James Bardin a5cb36b34c Allow moving instances to new resources
If a state mv target happens to be a resource that doesn't exist, allow
the creation of the new resource inferring the EachMode from the target
address.
2019-12-05 17:38:52 -05:00
Kristin Laemmert c9d62bb2f6
command: discard output from flags package and return errs directly (#22373)
Any command using meta.defaultFlagSet *might* occasionally exit before
the flag package's output got written. This caused flag error messages
to get lost. This PR discards the flag package output in favor of
directly returning the error to the end user.
2019-08-16 08:31:21 -04:00
James Bardin 32f7f58345 allow moving resource to new modules not in state
Create the missing modules in the state when moving resources to a
module that doesn't yet exist. This allows for refactoring of
configuration into new modules, without having to create dummy resources
in the module before the "state mv" operations.
2019-08-01 18:54:09 -04:00
Martin Atkins c39905e1a8 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-18 09:19:55 -07:00
Sander van Harmelen fb57e9b26f command/state: add proper locking 2019-01-08 14:57:52 +01:00
Sander van Harmelen ef9054562e commands: make sure the correct flagset is used
A lot of commands used `c.Meta.flagSet()` to create the initial flagset for the command, while quite a few of them didn’t actually use or support the flags that are then added.

So I updated a few commands to use `flag.NewFlagSet()` instead to only add the flags that are actually needed/supported.

Additionally this prevents a few commands from using locking while they actually don’t need locking (as locking is enabled as a default in `c.Meta.flagSet()`.
2018-11-23 16:13:34 +01:00
Sander van Harmelen 7ec3f96e3a command/state: update and fix the state mv command 2018-10-27 15:01:07 +02:00
Sander van Harmelen 536c2fe6f1 Make `state mv` use the new `states.Filter` 2018-10-19 19:19:49 +02:00
Martin Atkins 43d5206d82 command: Stub the "terraform state mv" tests to remind to fix
This command isn't yet updated for the new state types, but since we were
not returning a non-successful error status here the tests were just
failing in a weird way instead. Now we'll fail with a message that makes
it clear there is still work to do in the real implementation here.
2018-10-16 19:14:11 -07:00
Martin Atkins a3403f2766 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-10-16 19:11:09 -07:00
James Bardin 55d18dcef2 update state rm amd mv docs
Update the documentation to match the current behavior, and make the
usage output and website docs match.
2017-08-03 13:24:23 -04:00
James Bardin 5b4ae36cb0 don't print help for state loading errors
These already include detailed messages, and it's not a usage issue,
it's a config or file location issue.
2017-07-27 18:06:47 -04:00
James Bardin 33ba6774e0 Make the state commands use the real command.Meta
In order to use a backend for the state commands, we need an initialized
meta. Use a single Meta instance rather than temporary ones to make sure
the backends are initialized properly.
2017-07-27 15:33:50 -04:00
James Bardin 45a9edb763 make state mv and rm work with remote states
The default value for the -state flag was overriding the location of any
remote state.
2017-07-27 09:41:39 -04:00
Robert Liebowitz 006744bfe0 Use all tfvars files in working directory
As a side effect, several commands that previously did not have a failure
state can now fail during meta-parameter processing.
2017-07-05 17:24:17 -07:00
James Bardin 833cc9a6c5 Fix state mv/rm -backup documentation
There is only one backup made, contrary to the help text. We may want to
implement that, but the documentation should match the current behavior.
2017-06-23 14:46:09 -04:00
Edward Betts be265479a9 correct spelling mistakes (#13979) 2017-04-27 02:10:04 +12:00
Mitchell Hashimoto d2d87bccf0 Merge pull request #12155 from hashicorp/b-state-backend
command: refresh state in old commands for backend
2017-02-22 18:40:55 -08:00
Mitchell Hashimoto ebb22d3ecd
backend/local: don't RefreshState on State API 2017-02-22 13:01:16 -08:00
Mitchell Hashimoto e4d2193ed6
command/state: mv and rm -backup works
Fixes #12154

The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior:
it would change the _destination_ state and actually not create any
additional backup at all (the original state was unchanged and the
normal timestamped backup still are written). Really weird.

This PR makes the -backup flag work as you'd expect with one caveat:
we'll _still_ create the timestamped backup file. The timestamped backup
file helps make sure that you always get a backup history when using
these commands. We don't want to make it easy for you to overwrite a
state with the `-backup` flag.
2017-02-21 21:10:03 -08:00
Mitchell Hashimoto 6e1dc9c77d
command: extra RefreshState calls 2017-02-21 20:35:43 -08:00
Mitchell Hashimoto d3792e4aef
command: correct outdated comment 2016-08-19 23:56:27 -04:00
Mitchell Hashimoto 43cfd3d1c9
command: fix regressions for state mv with count resource 2016-08-19 12:09:19 -04:00
Mitchell Hashimoto 0d1ea84d39
command: test for moving resource with count [GH-7797] 2016-08-19 12:05:20 -04:00
Mitchell Hashimoto 3b3f92cd9b
terraform: fix some test failures on state add with multiple modules 2016-08-18 17:39:07 -04:00
James Nugent aa5dc453ee cli: Fix registration of `state mv`.
Fixes #7259.
2016-06-22 11:46:38 +03:00
Mitchell Hashimoto 04598baa25
website: document state mv 2016-05-10 13:25:42 -07:00
Mitchell Hashimoto c966a70ff9
command: update docs for state mv 2016-05-10 13:25:04 -07:00
Mitchell Hashimoto 235e860118
command/state mv: handle -state-out to a different path 2016-05-10 13:25:04 -07:00
Mitchell Hashimoto c4e5355a02
command/state mv 2016-05-10 13:25:03 -07:00