78 Commits (ba7679b6791a306a73062ddd5a00359452e152fc)

Author	SHA1	Message	Date
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	6 years ago
James Bardin	7f5ffbfe90	Merge pull request #21439 from hashicorp/jbardin/init-backend ... init always prompts for migration with most remote backend configurations	7 years ago
James Bardin	c017149b31	don't store prepared backend config ... The backend gets to "prepare" the configuration before Configure is called, in order to validate the values and insert defaults. We don't want to store this value in the "config state", because it will often not match the raw config after it is prepared, forcing unecessary backend migrations during init. Since PrepareConfig is always called before Configure, we can store the config value directly, and assume that it will be prepared in the same manner each time.	7 years ago
James Bardin	ee9a618369	don't migrate backend during init without override ... If the backend config hashes match during init, and there are no new backend override options, then we assume the existing config is OK. Since init should be idempotent, we should be able to run init with no options or config changes, and not effect the backends at all.	7 years ago
James Bardin	cefc927e48	failing test for backend re-init	7 years ago
Sander van Harmelen	d9ba0c69ea	Always try to select a workspace after initialization ... There are a number of use cases that can require a user to select a workspace after initializing Terraform. To make sure we cover all these use cases, we will always call the selectWorkspace method to verify a valid workspace is already selected or (if needed) offer to select one before moving on.	7 years ago
Sander van Harmelen	973e2a7cf9	core: add a context to the UIInput interface	7 years ago
James Bardin	2adf5801d9	don't panic of the users aborts backend input ... When the user aborts input, it may end up as an unknown value, which needs to be converted to null for PrepareConfig. Allow PrepareConfig to accept null config values in order to fill in missing defaults.	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
James Bardin	9667e06a03	decode backend hash as uint64 ... Older versions of terraform could save the backend hash number in a value larger than an int. While we could conditionally decode the state into an intermediary data structure for upgrade, or detect the specific decode error and modify the json, it seems simpler to just decode into the most flexible value for now, which is a uint64.	7 years ago
Martin Atkins	27abd9c6b8	command: Fix TestMetaBackend_localDoesNotDeleteLocal ... The changes to how we handle setting the state path on the local backend broke the heuristic we were using here for detecting migration from one local backend to another with the same state path, which would by default end up deleting the state altogether after migration. We now use the StatePaths method to do this, which takes into account both the default values and any settings that have been set. Additionally this addresses a flaw in the old method which could potentially have deleted all non-default workspace state files if the "path" setting were changed without also changing the "workspace_dir" setting. This new approach is conservative because it will preserve all of the files if any one overlaps.	7 years ago
Martin Atkins	be79bf0412	command: Fix TestPlan_outBackend ... In an earlier change we fixed the "backendFromConfig" codepath to be able to properly detect changes to the -backend-config arguments during "terraform init", but this detection is too strict for the normal case of running an operation in a previously-initialized directory. Before any of the recent changes, the logic here was to selectively update the hash to include -backend-config settings in the init case. Since that late hash recalculation was confusing, here we take the alternative path of using the hash only in the normal case and full value comparison in the init case. Treating both of these cases separately makes things marginally easier to follow here.	7 years ago
Martin Atkins	2b9f92be31	command: Partially fix TestMetaBackend_planLocalStatePath ... This test is testing some strange implementation details of the old local backend which do not hold with the new filesystem state manager. Specifically, it was expecting state to be read from the stateOutPath rather than the statePath, which makes no sense here because the backend is configured to read from the default terraform.tfstate file (which does not exist.) There is another problem with this test which will be addressed in a subsequent commit.	7 years ago
Martin Atkins	24046ab833	command: More TRACE logging for the Backend instantiation codepaths	7 years ago
Martin Atkins	c0b7f58143	command: Fix detection of necessary backend migration ... In the refactoring for new HCL this codepath stopped taking into account changes to the CLI -backend-config options when deciding if a backend migration is required. This restores that behavior in a different way than it used to be: rather than re-hashing the merged config and comparing the hashes, we instead just compare directly the configuration values, which must be exactly equal in order to skip migration. This change is covered by the test TestInit_inputFalse, although as of this commit it is still not passing due a downstream problem within the migration code itself.	7 years ago
Sander van Harmelen	5e9414bf03	backend/migrations: only select workspaces if supported ... If the backend does not support workspaces, we don't have to try to select a workspace and we should not return an error.	7 years ago
Martin Atkins	b5547f00f6	command: backendConfig must mutate its copy, not the original ... Here we were going to the trouble of copying the body so we could mutate it, but then ended up mutating the original anyway and then returning the unmodified copy. Whoops! This fix is verified by a number of "init" command tests that exercise the -backend-config option, including TestInit_backendConfigFile and several others whose names have the prefix TestInit_backendConfig .	7 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.	7 years ago
Sander van Harmelen	5944e8e34f	Fix the ability to ask for and save user input	7 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.	7 years ago
Martin Atkins	e8240087fe	command: Populate backend configuration in plan files ... In previous work we didn't quite connect these dots. The connection here is sub-awesome since the existing interfaces here had some unfortunate assumptions that we'd like to move away from (like the idea of a "nil backend" implying the local backend) but we're accepting this for now to avoid another big round of refactoring. The main implication of this is that we will now always include a backend configuration in the plan, though it might just be a placeholder config for the local backend in the remaining cases where that's still implicitly set. Later we will change this so that there is no implicit local backend at all (terraform init is always required, _it_ will deal with setting implicitly setting the local backend when appropriate), which will allow us to rework this to be more straightforward and less "spooky".	7 years ago
Martin Atkins	cbc548eb36	command: Do CLI init of backend loaded from plan ... If we don't do this, we can't produce any output when applying a saved plan file. Here we also introduce a check to the local backend's ReportResult function so that it won't panic if CLI init is skipped, although that will no longer happen in the apply-from-file case due to the change described in the previous paragraph.	7 years ago
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 5861dbf3fc before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.	7 years ago
Martin Atkins	ebafa51723	command: Various updates for the new backend package API ... This is a rather-messy, complex change to get the "command" package building again against the new backend API that was updated for the new configuration loader. A lot of this is mechanical rewriting to the new API, but meta_config.go and meta_backend.go in particular saw some major changes to interface with the new loader APIs and to deal with the change in order of steps in the backend API.	7 years ago
Martin Atkins	5782357c28	backend: Update interface and implementations for new config loader ... 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".	7 years ago
Sander van Harmelen	67db9da000	Add checks for all flags we currently don’t support ... For Plan only: -module-depth=n For Plan & Apply -parallelism=m -refresh=false -var “foo=bar” and -var-file=foo	7 years ago
Sander van Harmelen	1696ade924	backend/migrations: check all workspaces ... This commit fixes a bug that (in the case of the `local` backend) would only check if the selected workspace had a state when deciding to preform a migration. When the selected workspace didn’t have a state (but other existing workspace(s) did), the migration would not be preformed and the other workspaces would be ignored.	8 years ago
Sander van Harmelen	495d1ea350	Use New() instead of `once.Do(b.init)`	8 years ago
Sander van Harmelen	97d1c46602	Update the backend import names ... It’s a purely cosmetic change, but I find it easier to read them like this.	8 years ago
Kristin Laemmert	b8a1a77f6b	command: fix spelling in error message - fixes #18065 (#18241)	8 years ago
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.	8 years ago
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.	8 years ago
Masayuki Morita	f440dba137	Standardize on log level "WARN" rather than "WARNING"	8 years ago
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.	8 years ago
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.	8 years ago
Martin Atkins	0fe43c8977	cli: allow disabling "next steps" message in terraform plan ... In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.	9 years ago
David Glasser	039d36bf91	command: add "apply -auto-approve=false" flag ... 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.	9 years ago
Patrick Aikens	7775ef809b	Display correct to and from backends in copy message when migrating to new remote state (#15318)	9 years ago
James Bardin	6728c48d8c	fix whitespace around backend init success message ... make it better match the surrounding messages.	9 years ago
Martin Atkins	f7ce6a15f8	backend: Operation.Environment renamed to "Workspace" ... This is part of an effort to switch this terminology across all of Terraform.	9 years ago
Martin Atkins	418a8a8bc9	command + backend: rename various API objects to "Workspace" terminology ... We're shifting terminology from "environment" to "workspace". This takes care of some of the main internal API surface that was using the old terminology, though is not intended to be entirely comprehensive and is mainly just to minimize the amount of confusion for maintainers as we continue moving towards eliminating the old terminology.	9 years ago
Martin Atkins	5f9f13ab8f	command: show warnings from backend config validation ... Previously we just silently ignored warnings from validating the backend config, but now that we have a deprecated argument it's important to print these out so users can respond to the deprecation warning.	9 years ago
James Bardin	718ede0636	have Meta.Backend use a Config rather than loading ... Instead of providing the a path in BackendOpts, provide a loaded *config.Config instead. This reduces the number of places where configuration is loaded.	9 years ago
David Glasser	783908ee25	core: fix bad Sprintf in backend migration message (#14601) ... Before this, invoking this codepath would print Terraform has successfully migrated from legacy remote state to your configured remote state.%!(EXTRA string=s3)	9 years ago
Edward Betts	be265479a9	correct spelling mistakes (#13979)	9 years ago
James Bardin	7aa2ce8341	add -reconfigure option for init ... The reconfigure flag will force init to ignore any saved backend state. This is useful when a user does not want any backend migration to happen, or if the saved configuration can't be loaded at all for some reason.	9 years ago
James Bardin	d059939f88	Merge pull request #13262 from hashicorp/jbardin/lock-timeouts ... lock timeouts	9 years ago
James Bardin	5eca913b14	add cli flags for -lock-timeout ... Add the -lock-timeout flag to the appropriate commands. Add the -lock flag to `init` and `import` which were missing it. Set both stateLock and stateLockTimeout in Meta.flagsSet, and remove the extra references for clarity.	9 years ago
James Bardin	305ef43aa6	provide contexts to clistate.Lock calls ... 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.	9 years ago
James Bardin	3f0dcd1308	Have the clistate Lock use LockWithContext ... - Have the ui Lock helper use state.LockWithContext. - Rename the message package to clistate, since that's how it's imported everywhere. - Use a more idiomatic placement of the Context in the LockWithContext args.	9 years ago