Commit Graph

945 Commits

Author SHA1 Message Date
James Bardin 90a75422fb unlock state in console, import, graph, and push
The state locking improvements for the regular command had the side
effect of locking the state in the console, import, graph and push
commands. Those commands had been updated to get a state via the
Backend.Context method, which locks the state whenever possible, and now
need to call Unlock directly.

Add Unlock calls to all commands that call Context directly.
2018-03-21 12:13:40 -04:00
Martin Atkins 6aefa5835c Merge #17218: Add -auto-approve to "terraform destroy" for consistency 2018-03-08 17:42:15 -08:00
James Bardin dc8036636a
Merge pull request #17422 from hashicorp/jbardin/state-locking
Add StateLocker interface to backend operations
2018-02-27 11:38:55 -05:00
James Bardin 2b97585d46 improve clistate.Locker docs 2018-02-27 10:49:06 -05:00
Uriel Corfa 07a20365de cli: "terraform state list" -id argument
A new -id option to "terraform state list" which constraints the output of the command to resources whose id is equal to the flag value.
2018-02-26 10:54:48 -08:00
James Bardin bdd475e149 use the new clistate.Locker in commands
Use the new StateLocker field to provide a wrapper for locking the state
during terraform.Context creation in the commands that directly
manipulate the state.
2018-02-23 16:48:15 -05:00
James Bardin e9a76808df create clistate.Locker interface
Simplify the use of clistate.Lock by creating a clistate.Locker
instance, which stores the context of locking a state, to allow unlock
to be called without knowledge of how the state was locked.

This alows the backend code to bring the needed UI methods to the point
where the state is locked, and still unlock the state from an outer
scope.

Provide a NoopLocker as well, so that callers can always call Unlock
without verifying the status of the lock.

Add the StateLocker field to the backend.Operation, so that the state
lock can be carried between the different function scopes of the backend
code. This will allow the backend context to lock the state before it's
read, while allowing the different operations to unlock the state when
they complete.
2018-02-23 16:48:15 -05:00
James Bardin 12bda53558 Revert "create clistate.Locker interface"
This reverts commit e88bd74bb7.
2018-02-23 11:31:13 -05:00
James Bardin 3de0d24554 Revert "use the new clistate.Locker in commands"
This reverts commit 400f6ca4c5.
2018-02-23 11:31:06 -05:00
James Bardin 400f6ca4c5 use the new clistate.Locker in commands
Use the new StateLocker field to provide a wrapper for locking the state
during terraform.Context creation in the commands that directly
manipulate the state.
2018-02-23 11:28:47 -05:00
James Bardin e88bd74bb7 create clistate.Locker interface
Simplify the use of clistate.Lock by creating a clistate.Locker
instance, which stores the context of locking a state, to allow unlock
to be called without knowledge of how the state was locked.

This alows the backend code to bring the needed UI methods to the point
where the state is locked, and still unlock the state from an outer
scope.
2018-02-23 11:21:21 -05:00
James Bardin a37acb1837 gofmt with go1.10 2018-02-21 10:22:08 -05:00
James Bardin ecd9ef0f77 ignore error in plan shutdown test
The error was being silently dropped before.

There is an interpolation error, because the plan is canceled before
some of the resources can be evaluated. There might be a better way to
handle this in the walk cancellation, but the behavior has not changed.

Make the plan and apply shutdown match implementation-wise
2018-02-12 11:56:54 -05:00
James Bardin 67a6152091 move backend operation cancellation into meta
Create a single command method for running and operation with
cancellation.
2018-02-12 11:56:54 -05:00
James Bardin 7cba68326a always wait for a RunningOperation to return
If the user wishes to interrupt the running operation, only the first
interrupt was communicated to the operation by canceling the provided
context. A second interrupt would start the shutdown process, but not
communicate this to the running operation. This order of event could
cause partial writes of state.

What would happen is that once the command returns, the plugin system
would stop the provider processes. Once the provider processes dies, all
pending Eval operations would return return with an error, and quickly
cause the operation to complete. Since the backend code didn't know that
the process was shutting down imminently, it would continue by
attempting to write out the last known state. Under the right
conditions, the process would exit part way through the writing of the
state file.

Add Stop and Cancel CancelFuncs to the RunningOperation, to allow it to
easily differentiate between the two signals. The backend will then be
able to detect a shutdown and abort more gracefully.

In order to ensure that the backend is not in the process of writing the
state out, the command will always attempt to wait for the process to
complete after cancellation.
2018-02-12 11:56:03 -05:00
Laura Martin 6e1e614a56 Change -force to -auto-approve when destroying
Since an early version of Terraform, the `destroy` command has always
had the `-force` flag to allow an auto approval of the interactive
prompt. 0.11 introduced `-auto-approve` as default to `false` when using
the `apply` command.

The `-auto-approve` flag was introduced to reduce ambiguity of it's
function, but the `-force` flag was never updated for a destroy.

People often use wrappers when automating commands in Terraform, and the
inconsistency between `apply` and `destroy` means that additional logic
must be added to the wrappers to do similar functions. Both commands are
more or less able to run with similar syntax, and also heavily share
their code.

This commit updates the command in `destroy` to use the `-auto-approve` flag
making working with the Terraform CLI a more consistent experience.

We leave in `-force` in `destroy` for the time-being and flag it as
deprecated to ensure a safe switchover period.
2018-02-01 00:14:42 +00:00
James Bardin 6f41a80b3a slow down the plan shutdown tests for slow hosts
The plan shutdown test often fail on slow CI hosts, becase the plan
completes befor the main thread can cancel it. Since attempting to make
the MockProvider concurrent proved too invasive for now, just slow the
test down a bit to help ensure Stop gets called.
2018-01-31 17:09:48 -05:00
Masayuki Morita 338d5cad70 Remove duplicated help messages from `workspace --help`
Fixes #17165
2018-01-23 23:38:42 +09:00
Masayuki Morita f440dba137 Standardize on log level "WARN" rather than "WARNING" 2018-01-16 18:05:26 -08:00
Martin Atkins a6008b8a48
v0.11.2 2018-01-09 23:13:33 +00:00
James Bardin 61c2be3e95
Merge pull request #16969 from hashicorp/jbardin/reset-plugin-dir
allow init to reset -plugin-dir
2018-01-08 16:51:47 -05:00
James Bardin 7d5f7cb22f
Merge pull request #16961 from hashicorp/jbardin/mock-provider-race
minor race issue in mockResourceProvider
2018-01-08 16:47:58 -05:00
James Bardin 504ea578ee
Merge pull request #16920 from hashicorp/jbardin/init-future-state
check state version during init
2018-01-05 16:54:41 -05:00
James Bardin dec2da1dda
Merge pull request #17044 from hashicorp/jbardin/plugin-dir-internal
-plugin-dir short-circuits discovery of internal plugins
2018-01-05 16:54:28 -05:00
James Bardin 6367572455
Merge pull request #16882 from Techcadia/f-provider-logging
[Add] Pathing and Override to DEBUG Command
2018-01-05 12:25:24 -05:00
James Bardin fe3aff91f3 missingPlugins should not return internal plugins
Filter the internal plugins out beforehand, so we don't attempt to
locate them at all during init.
2018-01-05 11:52:11 -05:00
James Bardin 5a975d9997 add test for internal plugins with -plugin-dir
-plugin-dir was short-circuiting the discovery for internal plugins
2018-01-05 11:51:09 -05:00
James Bardin 5a9e0cf763 create a new InternalProviders test
Remove the legacy InternalProviders global.

The terraform provider is the only one run internally.
2018-01-05 10:59:30 -05:00
James Bardin ba84faf4e1 remove the plugin path only for an empty string
To avoid breaking automation where plugin-path was assumed to be set
permanently, only remove the plugin-path record if it was explicitly set
to and empty string.
2018-01-04 16:49:45 -05:00
James Bardin f62b71710a
Merge pull request #16939 from hashicorp/jbardin/migrate-confirm
remove extra backend migration prompts
2018-01-04 16:27:25 -05:00
James Bardin f45205feb7 re-word state migration prompts
The existing prompts were worded as if backend configurations were
named, but they can only really be referenced by their type. Change the
wording to reference them as type "X backend". When migrating state,
refer to the backends as the "previously configured" and "newly
configured", since they will often have the same type.
2018-01-04 16:22:54 -05:00
James Bardin 4b49a323c3 go fmt
slight change to go fmt coming in 0.10
2017-12-26 13:26:38 -05:00
James Bardin 79e985366f allow init to reset -plugin-dir
Remove the recorded -plugin-dir during init if the flag is not provided.
2017-12-21 11:21:07 -05:00
James Bardin d76482cd89 don't try to interrupt diff in shutdown test
Rather than relying on interrupting Diff, just make sure Stop was called
on the provider. The DiffFn is protected by a mutex in the mock
provider, which means that the tests can't rely on concurent calls to
diff working.
2017-12-20 16:23:55 -05:00
James Bardin e63a3474d5 kill the flag error writer after 2 seconds
There's no point in trying to track these, they're lost after each test.
Kill them after a short delay so we don't have goroutines from every single
command test to wade through if we have a stack dump.
2017-12-20 15:52:43 -05:00
James Bardin 885e4cde81 don't loop indefinitely in confirm method
Only check for input twice in the meta.confirm method. This prevents an
errant newline from aborting the run while allowing Terraform to exit if
there is no input available. We don't just check for a tty, since we
still rely on being able to pipe input in for testing.

Remove the redundant confirmation loops in the migration code, and only
use the confirm method.
2017-12-18 18:39:21 -05:00
James Bardin 7d2da9865e inputFalse test should attempt migration and check error
Make sure the init inputFalse test actually errors from missing input,
since skipping input will still fail later during provider
initialization. We need to make sure there are two different states that
aren't a noop for migration, and reset the command struct for each run.

Also verify that we don't go into an infinite loop if there is no input.
2017-12-18 18:39:21 -05:00
James Bardin 909dff36a8 remove extra "yes" confirmation in tests
There were two tests that had the duplicate confirmations hard-coded in
the input stream.
2017-12-18 11:42:33 -05:00
James Bardin 7c93b2e5e6 remove duplicate backend migration prompts
The duplicate prompts can be confusing when the user confirms that a
migration should happen and we immediately prompt a second time for the
same thing with slightly different wording. The extra hand-holding that
this provides for legacy remote states is less critical now, since it's
been 2 major release cycles since those were removed.
2017-12-18 11:42:33 -05:00
James Bardin ea4cb6a20e check state version during init
The init command needs to parse the state to resolve providers, but
changes to the state format can cause that to fail with difficult to
understand errors. Check the terraform version during init and provide
the same error that would be returned by plan or apply.
2017-12-15 11:17:59 -05:00
Martin Atkins f1079257ac command: show a special error message when importing in an empty dir
If users run "terraform import" in a directory with no Terraform
configuration files, it's likely that they've made a mistake either by
being in the wrong directory or forgetting to use the -config option
on the command line.

To help users find their mistake in this case, we'll now produce a
specialized error message for this situation:

    Error: No Terraform configuration files

    The directory /home/user/example does not contain any Terraform
    configuration files (.tf or .tf.json). To specify a different
    configuration directory, use the -config="..." command line option.

While here, this also converts some of the other existing messages to
diagnostics so that we can show any configuration warnings along with
the error message, and move towards the new standard error presentation.
2017-12-11 16:08:33 -08:00
Techcadia e681907c50 [Add] Pathing and Override Output to DEBUG Command 2017-12-08 13:12:23 -08:00
Nolan Davidson 653db95df7 Initial implementation of a habitat provisioner
First pass at loading the config data using the TF schema.

Signed-off-by: Nolan Davidson <ndavidson@chef.io>
2017-12-07 16:29:30 -08:00
Martin Atkins 9a5c865040 command: validate config as part of loading it
Previously we required callers to separately call .Validate on the root
module to determine if there were any value errors, but we did that
inconsistently and would thus see crashes in some cases where later code
would try to use invalid configuration as if it were valid.

Now we run .Validate automatically after config loading, returning the
resulting diagnostics. Since we return a diagnostics here, it's possible
to return both warnings and errors.

We return the loaded module even if it's invalid, so callers are free to
ignore returned errors and try to work with the config anyway, though they
will need to be defensive against invalid configuration themselves in
that case.

As a result of this, all of the commands that load configuration now need
to use diagnostic printing to signal errors. For the moment this just
allows us to return potentially-multiple config errors/warnings in full
fidelity, but also sets us up for later when more subsystems are able
to produce rich diagnostics so we can show them all together.

Finally, this commit also removes some stale, commented-out code for the
"legacy" (pre-0.8) graph implementation, which has not been available
for some time.
2017-12-07 14:28:43 -08:00
James Bardin 12b7dac124
Merge pull request #16833 from hashicorp/jbardin/plan-shutdown
Fully enable shutdown for plan and refresh in the local backend
2017-12-05 16:48:34 -05:00
Eyal Posener e1dadaae44 command: use newer version of "complete" library
This takes care of filtering results for us, so we don't need to do it on our end anymore.
2017-12-05 10:24:04 -08:00
James Bardin 2941ed464c replace the testShutdownHook with a check for Stop
Now that the local backend can be cancelled during plan and refresh, we
don't really need the testShutdownHook. Simplify the tests by just
checking for Stop being called on the provider.
2017-12-05 10:17:20 -05:00
James Bardin e2501d7830 make apply shutdown test completely deterministic
Add a shutdown hook to verify that a context has been correctly
cancelled, so we can remove the sleep and stop guessing.

Add a plan version of the shutdown test as well.
2017-12-01 15:56:49 -05:00
James Bardin 3aaa1e9d04 make plans cancellable
There was no cancellation context for a plan, so it would always have to
run to completion as SIGINT was being swallowed.

Move the shutdown channel to the command Meta since it's used in
multiple commands.
2017-12-01 13:14:44 -05:00
Martin Atkins ba0514106a return tfdiags.Diagnostics from validation methods
Validation is the best time to return detailed diagnostics
to the user since we're much more likely to have source
location information, etc than we are in later operations.

This change doesn't actually add any detail to the messages
yet, but it changes the interface so that we can gradually
introduce more detailed diagnostics over time.

While here there are some minor adjustments to some of the
messages to improve their consistency with terminology we
use elsewhere.
2017-11-28 11:15:29 -08:00