17 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

Author	SHA1	Message	Date
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.	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
Alisdair McDiarmid	f15e58adf8	Improve remote backend missing token error ... Prompt the user to run terraform login to generate and store a token for the configured remote backend.	6 years ago
Radek Simko	32f9722d9d	Replace import paths & set UA string where necessary	7 years ago
James Bardin	c814f2da37	Change backend.ValidateConfig to PrepareConfig ... This mirrors the change made for providers, so that default values can be inserted into the config by the backend implementation. This is only the interface and method name changes, it does not yet add any default values.	7 years ago
Sander van Harmelen	47a00ea34b	backend/remote: cleanup test connections ... Cleanup test connection to prevent file descriptor issues when running the tests on a Mac.	7 years ago
Sander van Harmelen	7b51af72b2	backend/remote: compare versions without the prerelease	7 years ago
Sander van Harmelen	55b6153b04	backend/remote: fix an error that prevents checking constraints	7 years ago
Sander van Harmelen	8f04e93739	backend/remote: return detailed incompatibility info	7 years ago
Sander van Harmelen	268c0f85ce	Add a method to retrieve version contraints	7 years ago
Sander van Harmelen	a5a2156584	core: enhance service discovery ... This PR improves the error handling so we can provide better feedback about any service discovery errors that occured. Additionally it adds logic to test for specific versions when discovering a service using `service.vN`. This will enable more informational errors which can indicate any version incompatibilities.	7 years ago
Sander van Harmelen	a17f317025	Change how to fall back from remote to local backend ... In order to support free organizations, we need a way to load the `remote` backend and then, depending on the used offering/plan, enable or disable remote operations. In other words, we should be able to dynamically fall back to the `local` backend if needed, after first configuring the `remote` backend. To make this works we need to change the way this was done previously when the env var `TF_FORCE_LOCAL_BACKEND` was set. The clear difference of course being that the env var would be available on startup, while the used offering/plan is only known after being able to connect to TFE.	8 years ago
Sander van Harmelen	52a1b22f7a	Implement the remote enhanced backend ... 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.	8 years ago
Martin Atkins	541952bb8f	Revert some work that happened since v0.12-dev branched ... This work was done against APIs that were already changed in the branch before work began, and so it doesn't apply to the v0.12 development work. To allow v0.12 to merge down to master, we'll revert this work out for now and then re-introduce equivalent functionality in later commits that works against the new APIs.	8 years ago
Sander van Harmelen	ea88daa499	backend/remote: add support for state locking	8 years ago
Sander van Harmelen	83d5f4147b	backend/remote: use schema max/min items options	8 years ago
Sander van Harmelen	7fb2d1b8de	Implement the Enterprise enhanced remote backend	8 years ago