This project is mirrored from https://:*****@github.com/hashicorp/terraform.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
- 26 Jan, 2021 1 commit
-
-
Jonathan Hall authored
-
- 12 Oct, 2020 1 commit
-
-
James Bardin authored
Now that outputs changes are tracked in full, we can remove the comparisons with the prior state and use the planned changes directly.
-
- 17 Sep, 2020 1 commit
-
-
James Bardin authored
This change refreshes the instance state during plan, so a complete Refresh no longer needs to happen before Plan.
-
- 11 Aug, 2020 1 commit
-
-
Kristin Laemmert authored
* unlock the state if Context() has an error, exactly as backend/remote does today * terraform console and terraform import will exit before unlocking state in case of error in Context() * responsibility for unlocking state in the local backend is pushed down the stack, out of backend.go and into each individual state operation * add tests confirming that state is not locked after apply and plan * backend/local: add checks that the state is unlocked after operations This adds tests to plan, apply and refresh which validate that the state is unlocked after all operations, regardless of exit status. I've also added specific tests that force Context() to fail during each operation to verify that locking behavior specifically.
-
- 29 May, 2020 1 commit
-
-
Martin Atkins authored
This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances.
-
- 21 Nov, 2019 1 commit
-
-
James Bardin authored
Located all non-test paths where a Diagnostic type was assigned to an error variable.
-
- 17 Sep, 2019 1 commit
-
-
Martin Atkins authored
The documentation for the -target option warns that it's intended for exceptional circumstances only and not for routine use, but that's not a very prominent location for that warning and so some users miss it. Here we make the warning more prominent by including it directly in the Terraform output when -target is in use. We first warn during planning that the plan might be incomplete, and then warn again after apply concludes and direct the user to run "terraform plan" to make sure that there are no further changes outstanding. The latter message is intended to reinforce that -target should only be a one-off operation and that you should always run without it soon after to ensure that the workspace is left in a consistent, converged state.
-
- 27 Mar, 2019 1 commit
-
-
Sander van Harmelen authored
When failing to write the state, the local backend writes the state to a local file called `errrored.tfstate`. Previously it would do so by creating a new state file which would use a new serial and lineage. By exorting the existing state file and directly assigning the new state, the serial and lineage are preserved.
-
- 08 Mar, 2019 1 commit
-
-
Sander van Harmelen authored
-
- 06 Mar, 2019 1 commit
-
-
Kristin Laemmert authored
replaced because the instance was tainted.
-
- 06 Nov, 2018 1 commit
-
-
Sander van Harmelen authored
This is a refactored version of the `remote` backend that was initially added to Terraform v0.11.8 which should now be compatible with v0.12.0.
-
- 17 Oct, 2018 7 commits
-
-
Martin Atkins authored
There are several steps here and a number of them can include reaching out to remote servers or executing local processes, so it's helpful to have some trace logs to better narrow down causes of errors and hangs during this step.
-
Kristin Laemmert authored
-
Kristin Laemmert authored
-
Martin Atkins authored
This is a light adaptation of our earlier prototype of structural diff rendering, as a starting point for what we'll actually ship. This is not consistent with the latest mocks, so will need some additional work before it is ready, but integrating this allows us to at least see the plan contents while fixing up remaining issues elsewhere.
-
Martin Atkins authored
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 5861dbf3 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
-
Martin Atkins authored
Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-...
-
Martin Atkins authored
The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
-
- 22 Sep, 2018 1 commit
-
-
Sander van Harmelen authored
-
- 19 Jun, 2018 1 commit
-
-
Kristin Laemmert authored
* cli: show workspace name in destroy confirmation If the workspace name is not "default", include it in the confirmation message for `terraform destroy`. Fixes #15480
-
- 23 Feb, 2018 5 commits
-
-
James Bardin authored
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.
-
James Bardin authored
This reverts commit e88bd74b.
-
James Bardin authored
This reverts commit 0b804a96.
-
James Bardin authored
Use the new StateLocker field to provide a wrapper for locking the state during terraform.Context creation. We can then remove all the state locking code from individual operations, and unlock them in one place inside the main Operation method.
-
James Bardin authored
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.
-
- 12 Feb, 2018 2 commits
-
-
James Bardin authored
Moves the nested select statements for backend operations into a single function. The only difference in this part was that apply called PersistState, which should be harmless regardless of the type of operation being run.
-
James Bardin authored
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.
-
- 01 Feb, 2018 1 commit
-
-
Laura Martin authored
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.
-
- 05 Dec, 2017 1 commit
-
-
James Bardin authored
Cancellation in the local backend was only implemented for apply.
-
- 02 Sep, 2017 2 commits
-
-
Martin Atkins authored
The previous diff presentation was rather "wordy", and not very friendly to those who can't see color either because they have color-blindness or because they don't have a color-supporting terminal. This new presentation uses the actual symbols used in the plan output and tries to be more concise. It also uses some framing characters to try to separate the different stages of "terraform plan" to make it easier to visually navigate. The apply command also adopts this new plan presentation, in preparation for "terraform apply" (with interactive plan confirmation) becoming the primary, safe workflow in the next major release. Finally, we standardize on the terminology "perform" and "actions" rather than "execute" and "changes" to reflect the fact that reading is now an action and that isn't actually a _change_.
-
Martin Atkins authored
Previously the rendered plan output was constructed directly from the core plan and then annotated with counts derived from the count hook. At various places we applied little adjustments to deal with the fact that the user-facing diff model is not identical to the internal diff model, including the special handling of data source reads and destroys. Since this logic was just muddled into the rendering code, it behaved inconsistently with the tally of adds, updates and deletes. This change reworks the plan formatter so that it happens in two stages: - First, we produce a specialized Plan object that is tailored for use in the UI. This applies all the relevant logic to transform the physical model into the user model. - Second, we do a straightforward visual rendering of the display-oriented plan object. For the moment this is slightly overkill since there's only one rendering path, but it does give us the benefit of letting the counts be derived from the same data as the full detailed diff, ensuring that they'll stay consistent. Later we may choose to have other UIs for plans, such as a machine-readable output intended to drive a web UI. In that case, we'd want the web UI to consume a serialization of the _display-oriented_ plan so that it doesn't need to re-implement all of these UI special cases. This introduces to core a new diff action type for "refresh". Currently this is used _only_ in the UI layer, to represent data source reads. Later it would be good to use this type for the core diff as well, to improve consistency, but that is left for another day to keep this change focused on the UI.
-
- 29 Jun, 2017 1 commit
-
-
James Bardin authored
-
- 27 Jun, 2017 3 commits
-
-
Martin Atkins authored
Some tweaks to the messaging and presentation.
-
David Glasser authored
-
David Glasser authored
A common reason to want to use `terraform plan` is to have a chance to review and confirm a plan before running it. If in fact that is the only reason you are running plan, this new `terraform apply -auto-approve=false` flag provides an easier alternative to P=$(mktemp -t plan) terraform refresh terraform plan -refresh=false -out=$P terraform apply $P rm $P The flag defaults to true for now, but in a future version of Terraform it will default to false.
-
- 25 May, 2017 1 commit
-
-
James Bardin authored
When the backend operation is cancelled, immediately call PersistState. The is a high likelihood that the user is going to terminate the process early if the provider doesn't return in a timely manner, so persist as much state as possible.
-
- 23 May, 2017 1 commit
-
-
Martin Atkins authored
In the old remote state system we had the idea of a local backup, which is actually still present for the legacy backends but no longer applies for the new-style backends like the s3 backend. It's problematic when an apply runs for long enough that someone's time-limited AWS STS credentials expire and then Terraform fails and can't persist state to S3. To reduce the risk of lost state, here we add some extra fallback code for the local apply operation in particular. If either state writing or state persisting fail then we attempt to write the state to a special backup file errored.tfstate, and produce an error message that guides the user on how to retry uploading this state. In the unlikely event that we can't write to local disk either (e.g. permissions problems) we take a last-ditch attempt to dump the JSON onto stdout and advise the user to manually copy it into a file for import. If even that doesn't work for some reason, we assume a critical Terraform bug (JSON-serialization problem with states?) and bail out with an apologetic error message. This is implemented for the apply command in particular because this is the one command where new objects are created in real APIs that we don't want to lose track of. For other operations it's less bad to just generate a simple error message and have the user retry. This fixes #14298.
-
- 25 Apr, 2017 1 commit
-
-
James Bardin authored
The backend apply operation doesn't need to output the same text as the cli itself. Instead notify the user that we are in the process of stopping the operation.
-
- 14 Apr, 2017 1 commit
-
-
James Bardin authored
The documentation for Refresh indicates that it will always return a valid state, but that wasn't true in the case of a graph builder error. While this same concept wasn't documented for Apply, it was still assumed in the terraform apply code. Since the helper testing framework relies on the absence of a state to determine if it can call Destroy, the Context can't can't start returning a state in all cases. Document this, and use the State method to fetch the correct state value after Apply. Add a nil check to the WriteState function, so that writing a nil state is a noop. Make sure to init before sorting the state, to make sure we're not attempting to sort nil values. This isn't technically needed with the current code, but it's just safer in general.
-
- 01 Apr, 2017 1 commit
-
-
James Bardin authored
Add fields required to create an appropriate context for all calls to clistate.Lock. Add missing checks for Meta.stateLock, where we would attempt to lock, even if locking should be skipped.
-