629 Commits (v0.13)

Author	SHA1	Message	Date
Alisdair McDiarmid	5e9cc234fe	Revert "backend: Validate remote backend Terraform version" ... This reverts commit 804a667749.	5 years ago
Alisdair McDiarmid	2fee60bbc8	Revert "backport of commit 6e0d8cde91fc9e2576bf7c7d6377e8d3e051594b" ... This reverts commit ea394d78de.	5 years ago
Alisdair McDiarmid	ea394d78de	backport of commit 6e0d8cde91	6 years ago
Alisdair McDiarmid	804a667749	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.	6 years ago
Alisdair McDiarmid	c8d7515808	backend: StateMgrWithoutCheckVersion ... Allow users of backends to initialize a state manager instance without checking the Terraform version of any state files which are retrieved during this process. Many backends call RefreshState as part of initialization, and this new method instead calls the new RefreshStateWithoutCheckVersion method to prevent version checking.	6 years ago
Alisdair McDiarmid	ff7382680d	states: Extract version check logic from read ... Instead of always checking the Terraform version associated with a state file when reading it, we add a CheckTerraformVersion method and call it from locations where we care about enforcing this check. For this commit, the check has been retained at all call sites for states/statefile.Read, with these exceptions: - Unit tests, which shouldn't care about the state file version; - E2E test runner which should always be using valid state files; - terraform.ShimLegacyState, where the check is pointless as the state file was just created by the current Terraform version.	6 years ago
James Bardin	276a8d9694	add missing Context argument	6 years ago
kt	e6e48abf43	AzureRM backend: correctly lookup environment from metadata host	6 years ago
Kirill Zaborsky	69b3bb50cd	Minor typo	6 years ago
Matt Kasa	c2e35ae3b5	backend/http: add support for configuration by environment variable (#25439)	6 years ago
Kristin Laemmert	196c183dda	terraform: remove state from `validate` graph walk (#26063) ... This pull reverts a recent change to backend/local which created two context, one with and one without state. Instead I have removed the state entirely from the validate graph (by explicitly passing a states.NewState() to the validate graph builder). This changed caused a test failure, which (ty so much for the help) @jbardin discovered was inaccurate all along: the test's call to `Validate()` was actually what was removing the output from state. The new expected test output matches terraform's actual behavior on the command line: if you use -target to destroy a resource, an output that references only that resource is *not* removed from state even though that test would lead you to believe it did. This includes two tests to cover the expected behavior: TestPlan_varsUnset has been updated so it will panic if it gets more than one request to input a variable TestPlan_providerArgumentUnset covers #26035 Fixes #26035, #26027	6 years ago
James Bardin	0c5430f88d	Merge pull request #25585 from chushenmeshile/master ... fix ossbackend only returned 100 workspaces	6 years ago
James Bardin	bd5ff98ca7	Merge pull request #25830 from hashicorp/kt/secret-metadata-host ... backend/azurerm: support loading environments from a metadata host	6 years ago
James Bardin	d46e9a4198	Merge pull request #25770 from hashicorp/f/azure-backend-spcert ... backend/azurerm: support for authenticating using a Client Certificate	6 years ago
Angie Pinilla	582fb73a7c	deps: Update aws-sdk-go-based to 0.6.0	6 years ago
kt	23b4c2db42	azurerm backend: support loading metadata from a given host	6 years ago
James Bardin	1c09df1a66	Merge pull request #25779 from hashicorp/jbardin/remove-state-attrs ... Remove resource state attributes that are no longer in the schema	6 years ago
Kristin Laemmert	6621501ae3	state: remove deprecated state package (#25490) ... Most of the state package has been deprecated by the states package. This PR replaces all the references to the old state package that can be done simply - the low-hanging fruit. * states: move state.Locker to statemgr The state.Locker interface was a wrapper around a statemgr.Full, so moving this was relatively straightforward. * command: remove unnecessary use of state package for writing local terraform state files * move state.LocalState into terraform package state.LocalState is responsible for managing terraform.States, so it made sense (to me) to move it into the terraform package. * slight change of heart: move state.LocalState into clistate instead of terraform	6 years ago
Kristin Laemmert	86e9ba3d65	* backend/local: push responsibility for unlocking state into individual operations ... * 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.	6 years ago
James Bardin	3cf84bb3f9	don't add state to the validate context ... The validate command should work with the configuration, but when validate was run at the start of a plan or apply command the state was inserted in preparation for the next walk. This could lead to errors when the resource schemas had changes and the state could not be upgraded or decoded.	6 years ago
tombuildsstuff	d215453495	backend/azurerm: adding a missing docs string. fixes #25765	6 years ago
tombuildsstuff	0d34e5d97c	backend/azurerm: support for authenticating using a Client Certificate ... fixes #24179 supersedes #19606 dependent on #25769	6 years ago
zjd	25de713214	fix ossbackend only returned 100 workspaces	6 years ago
Kristin Laemmert	604e65bb62	Revert "backend/local: release lock if there is an error in Context() (#25427)" ... This reverts commit 1ba0d615e7.	6 years ago
Kristin Laemmert	1ba0d615e7	backend/local: release lock if there is an error in Context() (#25427) ... * command/console: return in case of errors before trying to unlock remote state The remote backend `Context` would exit without an active lock if there was an error, while the local backend `Context` exited *with* a lock. This caused a problem in `terraform console`, which would call unlock regardless of error status. This commit makes the local and remote backend consistently unlock the state incase of error, and updates terraform console to check for errors before trying to unlock the state. * adding tests for remote and local backends	6 years ago
Even Holthe	0f85b283b9	Azure backend: support snapshots/versioning (#24069) ... * Azure backend: support snapshots/versioning Co-authored-by: Reda Ahdjoudj <reda.ahdjoudj@gmail.com> Co-authored-by: Patrick F. Marques <patrickfmarques@gmail.com> * Azure backend: Versioning -> Snapshot Co-authored-by: Reda Ahdjoudj <reda.ahdjoudj@gmail.com> Co-authored-by: Patrick F. Marques <patrickfmarques@gmail.com>	6 years ago
James Bardin	35d232481f	prevent panic in remote backend retry ... Ensure that the *http.Response is not nil before checking the status.	6 years ago
Petros Kolyvas	4a3d0118c6	Merge pull request #25139 from xiaozhu36/master ... backend/oss: supports setting HTTPS_PROXY	6 years ago
James Bardin	7800ef63d4	Merge pull request #19525 from dramich/k8sback ... backend/kubernetes: Add Kubernetes as a backend	6 years ago
John Houston	01ebdd27f2	Rework soak test to error on unlock failure	6 years ago
John Houston	b0f7e273e8	Add errors for lock disappearing	6 years ago
Brian Flad	ba081aa10a	backend/s3: Updates for Terraform v0.13.0 (#25134) ... * deps: Update github.com/hashicorp/aws-sdk-go-base@v0.5.0 Updated via: ``` $ go get github.com/hashicorp/aws-sdk-go-base@v0.5.0 $ go mod tidy $ go mod vendor ``` * backend/s3: Updates for Terraform v0.13.0 Reference: https://github.com/hashicorp/terraform/issues/13410 Reference: https://github.com/hashicorp/terraform/issues/18774 Reference: https://github.com/hashicorp/terraform/issues/19482 Reference: https://github.com/hashicorp/terraform/issues/20062 Reference: https://github.com/hashicorp/terraform/issues/20599 Reference: https://github.com/hashicorp/terraform/issues/22103 Reference: https://github.com/hashicorp/terraform/issues/22161 Reference: https://github.com/hashicorp/terraform/issues/22601 Reference: https://github.com/hashicorp/terraform/issues/22992 Reference: https://github.com/hashicorp/terraform/issues/24252 Reference: https://github.com/hashicorp/terraform/issues/24253 Reference: https://github.com/hashicorp/terraform/issues/24480 Reference: https://github.com/hashicorp/terraform/issues/25056 Changes: ``` NOTES * backend/s3: Deprecated `lock_table`, `skip_get_ec2_platforms`, `skip_requesting_account_id` arguments have been removed * backend/s3: Credential ordering has changed from static, environment, shared credentials, EC2 metadata, default AWS Go SDK (shared configuration, web identity, ECS, EC2 Metadata) to static, environment, shared credentials, default AWS Go SDK (shared configuration, web identity, ECS, EC2 Metadata) * The `AWS_METADATA_TIMEOUT` environment variable no longer has any effect as we now depend on the default AWS Go SDK EC2 Metadata client timeout of one second with two retries ENHANCEMENTS * backend/s3: Always enable shared configuration file support (no longer require `AWS_SDK_LOAD_CONFIG` environment variable) * backend/s3: Automatically expand `~` prefix for home directories in `shared_credentials_file` argument * backend/s3: Add `assume_role_duration_seconds`, `assume_role_policy_arns`, `assume_role_tags`, and `assume_role_transitive_tag_keys` arguments BUG FIXES * backend/s3: Ensure configured profile is used * backend/s3: Ensure configured STS endpoint is used during AssumeRole API calls * backend/s3: Prefer AWS shared configuration over EC2 metadata credentials * backend/s3: Prefer ECS credentials over EC2 metadata credentials * backend/s3: Remove hardcoded AWS Provider messaging ``` Output from acceptance testing: ``` --- PASS: TestBackend (16.32s) --- PASS: TestBackendConfig (0.58s) --- PASS: TestBackendConfig_AssumeRole (0.02s) --- PASS: TestBackendConfig_conflictingEncryptionSchema (0.00s) --- PASS: TestBackendConfig_invalidKey (0.00s) --- PASS: TestBackendConfig_invalidSSECustomerKeyEncoding (0.00s) --- PASS: TestBackendConfig_invalidSSECustomerKeyLength (0.00s) --- PASS: TestBackendExtraPaths (13.21s) --- PASS: TestBackendLocked (28.98s) --- PASS: TestBackendPrefixInWorkspace (5.65s) --- PASS: TestBackendSSECustomerKey (17.60s) --- PASS: TestBackend_impl (0.00s) --- PASS: TestForceUnlock (17.50s) --- PASS: TestKeyEnv (50.25s) --- PASS: TestRemoteClient (4.78s) --- PASS: TestRemoteClientLocks (16.85s) --- PASS: TestRemoteClient_clientMD5 (12.08s) --- PASS: TestRemoteClient_impl (0.00s) --- PASS: TestRemoteClient_stateChecksum (17.92s) ```	6 years ago
John Houston	e5f7237582	Soak test for kubernetes backend	6 years ago
Kristin Laemmert	e6cf6cd758	backend/remote: do not panic if PrepareConfig or Configure receive null (#25135) ... * backend/remote: do not panic if PrepareConfig or Configure receive null objects If a user cancels (ctrl-c) terraform init while it is requesting missing configuration options for the remote backend, the PrepareConfig and Configure functions would receive a null cty.Value which would result in panics. This PR adds a check for null objects to the two functions in question. Fixes #23992	6 years ago
He Guimin	5b4950e2cb	backend(oss): supports setting HTTPS_PROXY	6 years ago
John Houston	23fb8f6d21	Add kubernetes backend ... Co-authored-by: Dan Ramich <danold215@gmail.com>	6 years ago
Martin Atkins	31a4b44d2e	backend/local: treat output changes as side-effects to be applied ... 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.	6 years ago
Matthew Frahry	481b03c34a	Update azure backend storage sdk (#24669) ... * update vendored azure sdk * vendor giovanni storage sdk * Add giovanni clients * go mod vendor * Swap to new storage sdk * workable tests * update .go-version to 1.14.2 * Tests working minus SAS * Add SAS Token support * Update vendor * Passing tests * Add date randomizer * Captalize RG * Remove random bits * Update client var name Co-authored-by: kt <kt@katbyte.me>	6 years ago
CJ Horton	e1dcae17b7	add sad path tests for the TFP API version check	6 years ago
CJ Horton	68f199fc76	replace status string with go-tfe enum	6 years ago
Martin Atkins	8e1615a802	backend/remote: Handle cost estimation skipped due to targeting ... The remote server might choose to skip running cost estimation for a targeted plan, in which case we'll show a note about it in the UI and then move on, rather than returning an "invalid status" error. This new status isn't yet available in the go-tfe library as a constant, so for now we have the string directly in our switch statement. This is a pragmatic way to expedite getting the "critical path" of this feature in place without blocking on changes to ancillary codebases. A subsequent commit should switch this over to tfe.CostEstimateSkippedDueToTargeting once that's available in a go-tfe release.	6 years ago
CJ Horton	0eea4e7c62	prevent targeting for unsupported API versions	6 years ago
Mike Nomitch	650a272a1d	Change message sent to remote backend if -target used	6 years ago
Martin Atkins	16f1f3b739	backend/remote: Support -target on plan and apply ... Previously we did not allow -target to be used with the remote backend because there was no way to send the targets to Terraform Cloud/Enterprise via the API. There is now an attribute in the request for creating a plan that allows us to send target addresses, so we'll remove that restriction and copy the given target addresses into the API request.	6 years ago
Martin Atkins	db4f3f8bc5	vendor: go get github.com/hashicorp/go-tfe@v0.8.0 ... This includes a new TargetAddrs field on both Run and RunCreateOptions which we'll use to send resource addresses that were specified using -target on the CLI command line when using the remote backend. There were some unrelated upstream breaking changes compared to the last version we had vendored, so this commit also includes some changes to the backend/remote package to work with this new API, which now requires the remote backend to be aware of the remote system's opaque workspace id.	6 years ago
Pam Selle	60b3815af4	Merge pull request #24696 from hashicorp/leetrout/remote-state-force-push ... Add support for force pushing with the remote backend	6 years ago
Lee Trout	cb0e20ca2b	Add support for force pushing with the remote backend ... Both differing serials and lineage protections should be bypassed with the -force flag (in addition to resources). Compared to other backends we aren’t just shipping over the state bytes in a simple payload during the persistence phase of the push command and the force flag added to the Go TFE client needs to be specified at that time. To prevent changing every method signature of PersistState of the remote client I added an optional interface that provides a hook to flag the Client as operating in a force push context. Changing the method signature would be more explicit at the cost of not being used anywhere else currently or the optional interface pattern could be applied to the state itself so it could be upgraded to support PersistState(force bool) only when needed. Prior to this only the resources of the state were checked for changes not the lineage or the serial. To bring this in line with documented behavior noted above those attributes also have a “read” counterpart just like state has. These are now checked along with state to determine if the state as a whole is unchanged. Tests were altered to table driven test format and testing was expanded to include WriteStateForMigration and its interaction with a ClientForcePusher type.	6 years ago
Kritonas	71395a0656	Fixed minor grammatical errors	6 years ago
kayrus	bd344f9d73	Sync auth options with upstream openstack provider	6 years ago
kayrus	50084f5b17	gofmt -w -s	6 years ago